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LETTERS TO 
THE EDITOR 


Microprocessors defy 
classification 

The designation of a computer as 
8-bit, 16-bit, or 32-bit seems to be more a 
marketing decision by the manufacturer 
than anything else. Every definition I 
have heard results in an absurd designa¬ 
tion for some computer. For example, 
that offered by James Isaak in the 
December 1983 issue of IEEE Micro 
(Letters, page 3) would designate the 
IBM System/370 as a 12-bit computer. 

There is a consensus in the personal 
computer marketplace that the IBM PC 
is a 16-bit computer. Those writing about 
such systems have a difficult time ex¬ 
plaining how the 8086 differs from the 
8088. 

Hubert Kirrmann’s rather complex 
classification (December 1983, Letters, 
page 4) does seem to capture the essence 
of current microprocessors. The designa¬ 
tion is usually applied to the architecture 
of a processor rather than its implemen¬ 
tation, however. In his definition, both 
numbers are implementation-dependent, 
though the first is usually determined by 
architecture. The introduction of on- 
chip caches—already announced by 
several manufacturers—will soon render 
even this definition inadequate. 

James R. Goodman 
Computer Sciences Dept. 
University of Wisconsin—Madison 
1210 West Dayton Street 
Madison, WI 53706 


Author’s reply: 

The most important parameter of a 
processor seems to me to be its address 
size. Therefore, I proposed to classify a 
microprocessor by both its address and 
its data size and thus designated a 68000 
a 24+16 processor and an 8086 a 20/16 
processor (the slash means that address 
and data are multiplexed, while the plus 
sign means that they are not). Goodman 
is right to observe that a cache makes this 
definition inadequate to describe perfor- 

cont’t on page 6 




Use Pmate™ once, and you’ll 
never go back to an ordinary 
text editor again. Pmate is more 
than a powerful programmer’s 
text processor. It’s an inter¬ 
pretive language especially 
designed for customizing text 
processing and editing. 

Just like other powerful edi¬ 
tors, Pmate* features full-screen 
single-key editing, automatic 
disk buffering, ten auxiliary 
buffers, horizontal and vertical 
scrolling, plus a “garbage 
stack” buffer for retrieval of 
deleted strings. But, that’s just 
for openers. 

What really separates Pmate 
from the rest is macro magic. A 
built-in macro language with 
over 120 commands and single¬ 
keystroke “Instant Commands” 
to handle multiple command 


sequences. So powerful, you 
can “customize” keyboard 
and command structure to 
match your exact needs. 

Get automatic comments on 
code. Delete comments. Check 
syntax. Translate code from 
one language to another. Set 
up menus. Help screens. You 
name it. 

And, Pmate has its own set 
of variables, if-then statements, 
iterative loops, numeric calcu¬ 
lations, a hex to decimal and 
decimal to hex mode, binary 
conversion, and a trace mode. 
You can even build your own 
application program right 
inside your text processor. 

So, why work with primitive 
tools any longer than you have 
to? Pmate by Phoenix. $225. 
Call 1-800-344-7200. Or Write. 


‘Pmate is designed for microcomputers using the Intel 8086 family of 
processors, and running MS-DOS™ A custom version is available for 
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and Z80 running under CP/M™ 


Pmate is a trademark of Phoenix Software Associates Ltd. 

MS-DOS is a trademark of Microsoft Corporation. CP/M is a trademark of Digital Research, Inc. 


Phoenix Software Associates Ltd. 

1420 Providence Highway Suite 260 
Norwood, MA 02062 
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Factors of production 

by Congressman Norman Mineta 


Government can provide an environ¬ 
ment that is conducive to the success of 
business, and government can also erect 
obstacles which make success impossible. 
For example, the operations of business 
require public utilities, public educational 
systems, publicly funded research, and 
publicly regulated channels of transporta¬ 
tion and communication. But skewed 
governmental tax policies, misguided 
laws, and barriers to free competition can 
doom productive business. Willy nilly, 
high-technology business enterprises are 
inextricably linked to the policies of their 
government. 

As a member of Congress who repre¬ 
sents part of California’s Silicon Valley, I 
have seen that the semiconductor and 
electronics industries touch upon many of 
the most intriguing and contentious 
political questions of our day: military 
spending, social spending, monetary 
policy, trade policy, industrial policy, 
educational policy. 

Consider some of the most basic public 
policy questions now pending both here in 
the United States and in Europe and 
Japan. Should your government spend 
large portions of public revenues on 
military projects? Some may gain business 
from defense contracts, but others may 
suffer because America has a shortage of 
engineers for nonmilitary projects. More¬ 
over, others are hurt by the higher interest 
rates and inflated prices which result from 
high levels of military spending and 
bloated deficits. 

Should the government maintain, raise, 
or lower taxes? None of us likes giving up 
money. But business depends upon the 
goods and infrastructure provided with 
public funds. It depends upon roads and 
airports built with tax revenues. It 
depends upon technological advances 
provided by tax-subsidized research. It 
depends upon people whose training has 
been assisted by tax revenues. 

And, of course, we must ask ourselves 
questions about trade policies. The prob¬ 
lem is to protect ourselves against unfair 


trade practices without depriving our¬ 
selves of the benefits of free trade. Many 
employees are unable to move to another 
field or another section of the country; 
how should we deal with the fact that this 
week’s laid-off employees may not be the 
same person as next week’s new-hire? The 
fact is that people are not infinitely flex¬ 
ible and redeployable factors of produc¬ 
tion. Perhaps there are cases when our 
government should protect a declining 
firm or industry to lessen human dis¬ 
location. 

Some people prefer to avoid the 
arguments which these questions pro¬ 
voke. But the issues will not fade away. So 
there is plenty of controversy. But I 
believe that useful public policy depends 
upon the successful discovery of consen¬ 
sus. Despite the questions I have raised, I 
believe that there is a great deal of room 
for agreement in the policy issues affect¬ 
ing high-tech industries and in particular 
the electronics industry. Moreover, these 
realms of agreement have led to several 
current useful legislative proposals in the 
United States Congress. 

Research and development: antitrust. 
First and foremost we can agree that 
research and development provide the 
lifeblood on innovative, growing in¬ 
dustries. Firms in the electronics industry 
are buffeted in the tides of rapid tech¬ 
nological change, and their survival often 
depends upon their ability to rise with 
those tides. Here in the United States, our 
government has sometimes proven insensi¬ 
tive to their situation. As a result, entrep¬ 
reneurs may face some senseless prohibi¬ 
tions of antiturust law, some unreasonable 
taxes, and burdens because of insufficient 
funding for education and research. 

Efforts to adjust U.S. antitrust laws, in 
order to permit joint R&D vantures, offer 
us further room for agreement and pro¬ 
ductive action. Many U.S. companies 
have already joined together in R&D ven¬ 
tures, but the antitrust laws have not yet 
been changed to ensure that these com¬ 
panies will be free from burdensome and 


unnecessary antitrust challenges from 
other private parties or from the govern¬ 
ment. We Americans have witnessed the 
successes of foreign competitors who have 
been able to cooperate in basic R&D ven¬ 
tures, and these successes provide further 
strong arguments for promoting such 
associations in the U.S. By allowing our 
domestic companies to work together on 
R&D projects, our companies will be able 
to avoid unnecessary duplication of effort 
and inefficient use of resources. 

Just how the antitrust laws should be 
changed is still being debated. Some of the 
proposals currently being considered in¬ 
clude measures which would provide full 
or limited immunity from antitrust pro¬ 
secutions or a safety-net provision limiting 
antitrust penalties to actual damages or 
single-damages instead of the present 
triple-damage awards. Some proposals 
call for “safe harbors” if the venture can 
satisfy standards assuring probable lack 
of significant anticompetitive effects. The 
idea of the “safe harbor” is to permit 
businesses to undertake certain joint R&D 
projects with the knowledge that because 
the projects meet predetermined mini¬ 
mum standards assuring that anticompeti¬ 
tive results are unlikely, investments can 
safely be made in the projects without 
concern that antitrust problems will 
subsequently undermine the project. I 
think all of the current proposals deserve 
study, and in principle they warrant sup¬ 
port. Again, I believe that after hearing 
and considering the views of those con¬ 
cerned we can coalesce in agreement 
about the need for some reforms of U.S. 
antitrust laws. 

R&D: tax. These are fields calling for 
new congressional initiatives. For exam¬ 
ple, to spur investment in R&D, many of 
us in Congress supported legislation pro¬ 
viding tax credits for investment in 
research and development. In 1981, such 
legislation was enacted. Fortunately, the 
credits provided by that legislation have 
been highly successful in promoting new 
product development. But the credits 
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were provided only on a temporary basis, 
so it is important that support be dis¬ 
played for proposed legislation for the 
development of new products which is 
now before Congress—legislation to ex¬ 
tend the R&D tax credit and make it a per¬ 
manent part of our tax code. I support 
that legislation. Moreover, it is important 
that the legislation that emerges gives fair 
treatment to all important forms of R&D, 
such as computer software as well as hard¬ 
ware. 

Even the sticky issue of taxes can, I 
believe, invite productive agreement. 
Policy makers in Washington have begun 
to appreciate the fact that while President 
Reagan’s Economic Recovery Act of 1981 
provided a windfall for traditional and 
“smokestack” industries, it did little for 
high-technology industries. In 1981, too 
few understood that high-technology 
companies depend upon relatively short¬ 
lived equipment to survive in a constantly 
changing industry. As a result of that 
oversight, the 1981 Recovery Act provi¬ 
ded tax breaks for traditional, capital- 
intensive, “smokestack” industries—tax 
breaks which were nearly irrelevant for 
the high-technology electronics industries. 
It is now time to cooperate in an effort to 
get such industries some reasonable depre¬ 
ciation provisions in the U.S. tax 
code—provisions which will benefit high- 
growth electronics companies. 

Chip protection. Representing Silicon 
Valley, I have also become acutely con¬ 
scious of the fact that the special nature of 
R&D for silicon chips requires further 
legislative reforms. Representative Don 
Edwards and I have introduced the Semi¬ 
conductor Computer Chip Protection Act 
(H.R. 1028) in the U.S. House of 
Representatives to address this fact. Our 
bill provides much needed copyright pro¬ 
tection for the layouts and mask patterns 
of computer chips. Legal acknowledge¬ 
ment of the property rights of the owner 
of a chip layout embodied in mask designs 
will ensure that the time and money spent 
by a company to develop a new chip will 
be a worthwhile investment. Innovating 
firms often spend years, thousands of 
engineering manhours, and millions of 
dollars in order to develop a new large- 
scale integrated semiconductor circuit 
design. Yet a competing firm can photo¬ 
graph a chip and thus duplicate the masks 
used to make it, in only a few months and 
for a cost as low as $50,000. Once again, I 
believe that we can agree—we can agree 
on the basic principle that reasonable 
copyright protection is both fair and pro¬ 
ductive. And that principle can help move 
us toward the legislative reform embodied 
in the Semiconductor Chip Protection 
Act. 

Education. Of course, neither incen¬ 
tives for R&D nor tax credits for rapidly 
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It’s time you got Plink86™ the 
overlay linkage editor that’s 
bringing modular programming 
to Intel 8086-based micros. 

With Plink86r you can write a 
program as large and complex 
as you want and not worry about 
whether it will fit within available 
memory constraints. You can 
divide your program into any 
number of tree-structured over¬ 
lay areas. 4095 by 32 deep. 
Work on modules individually. 
Then link them into executable 
files. All without making changes 
to your source program 
modules. 

Use the same module in dif¬ 
ferent programs. Experiment 
with changes to the overlay 
structure of an existing program. 
Use one overlay to access code 


and data in other overlays. 

Plink86 is a two-pass linkage 
editor that links modules cre¬ 
ated by the Microsoft assembler 
or any of Microsoft’s 8086 com¬ 
pilers. Plink86 also works with 
other popular languages, like 
Lattice C, C86, or mbp/COBOL. 
And supports symbolic debug¬ 
ging with Phoenix’ Pfix86 Plus™ 

Plink86 includes its own ob¬ 
ject module library manager - 
Plib86™ - that lets you build 
libraries from scratch. Add or 
delete modules from existing 
libraries... Merge libraries... 

Or produce cross-reference 
listings. 

Why squeeze any more than 
you have to? Plink86 by Phoenix. 
$395. Call (1) 800-344-7200. 

Or, write. 


Phoenix Software Associates Ltd. 

1420 Providence Highway Suite 260 
Norwood, MA 02062 
In Massachusetts 16171769-7020 


*Plink86 will run under PC DOS, MS-DOS™ or CP/M™-86. 

Plink86, Pfix86 Plus and Plib86 are trademarks of Phoenix Software Associates Ltd. 
MS-DOS is a trademark of Microsoft Corporation. CP/M is a trademark of Digital Research, Inc. 
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depreciating capital can take full, bene¬ 
ficial effect if our electronics companies 
do not have the trained personnel neces¬ 
sary to utilize opportunities in high-tech 
industries. There can be no doubt that the 
international technological revolution has 
caught the United States understaffed and 
surprisingly undereducated. You may 
have heard about the American Elec¬ 
tronics Association report which conclu¬ 
ded that America’s educational system 
needs to triple its output of electrical and 
computer science engineers in the next five 
years if it is going to meet the needs of the 
electronics industry alone. Indeed, it is 
staggering to consider the small number of 
people on whom the United States 
depends for its technological expertise. 
For example, out of 200 million 
Americans, only 1000 are trained to 
design large-scale integrated circuits. 

In recognition of such deficiencies, the 
United States House of Representatives 
has passed the Math and Science Educa¬ 
tion Act of 1983. This bill authorizes 
funds to improve and increase math and 
science education at all levels in America, 
to update facilities in our university 
laboratories, and to promote stronger ties 
between research in our universities and 
innovations in our private industries. That 
bill is currently being considered in the 
Senate, and I hope that we can also 
cooperate in an effort to get the Math and 
Science Education Act passed in Congress 
and signed into law. 

Yet we must do more than offer seed 
money to improve our academic environ¬ 
ment. The U.S. government will have to 
offer more than that to help update our 
educational systems and provide the 
crucial braintrust necessary for the success 
of your industries. I am now supporting 
measures in the House of Representatives 
to provide tax credits to companies 
donating computers and other scientific 
equipment to our nation’s schools. That is 
probably only one of many bills which 
could get private companies to help im¬ 
prove the technological education provi¬ 
ded by our schools. For example, I feel 
that the federal government could and 
should cooperate in some way with pri¬ 
vate firms in the effort to provide a suffi¬ 
cient supply of high-calibre educators. 
Concerned citizens in Silicon Valley have 
begun to worry about the “Brain Drain” 
developing as firms hire away vitally need¬ 
ed professors. I think we can all agree that 
Congress, private industry, and the educa¬ 
tional community should work together 
to help preserve our nation’s precious sup¬ 
ply of teachers, so that we will have people 
who will train the next generation of scien¬ 
tists and technologists—and not, in effect, 
eat our own seed corn. 

Trade. There is another point on which 
we can all agree—that is that without in¬ 


ternational trade, the electronics in¬ 
dustries would suffer immensely. And if 
all the measures I have discussed are to 
bear their full and fair dividends, we must 
also address the state of world trade itself. 
The current administration has imposed 
severe and unnecessary restrictions on the 
export of many technological products, 
thousands of products which our military 
adversaries neither want nor need and 
which are readily available from other 
sources. As a result, business people have 
to wade through a sea of bureaucratic red 
tape. Again, I think we can agree on ap¬ 
propriate legislative redress. We should 
adjust the legislation which allows all of 
these unnecessary and detrimental restric¬ 
tions, the Export Administration Act. In 
Congress, we have been working to 
amend that legislation so that only the 
trade restrictions which truly promote our 
national security will remain in place. 
Here again, we should remind those who 
hesitate that our national security depends 
upon vigorous trade as well as military 
might. 

Involvement. All of these initiatives ad¬ 
dress specific concerns of the electronics 
industries. But I think it is important also 
to try to grapple with a wider array of 
public policy issues. As the high-tech¬ 
nology lobby matures, there may be a 
great temptation to think only about 
devising a menu of tax credits or public in¬ 
centives which affect your balance sheets. 
But it must be recognized that all decisions 
about high-technology issues in the public 
sector will have to be made within the con¬ 
text of larger decisions about our future. 


Letters 

corn’d from p. 3 

mance. If the 8086 (20/16) and the 8088 
(20/8) both had an on-chip cache with a 
hit ratio of 95 percent, the performance 
difference between them would matter 
only five percent of the time. The hard¬ 
ware designer must be aware of the dif¬ 
ference all of the time, however. Good¬ 
man is also right to point out that my 
classification does not necessarily reflect 
the architecture as the programmer sees 
it. Even the external address size can be 
controversial—the Microvax’s address 
size of 28 bits is larger than the physically 
available 22-bit address on the Q-bus. 
Single-board computers and signal pro¬ 
cessors are difficult to describe. Yet, the 
address and data that come out of the 
chip (or out of the board) are good in¬ 
dicators of the architecture and of the 
implementation, respectively. 


Therefore, just as government provides 
essential factors of production for in¬ 
dustry, concerned citizens must provide 
the essential factors of production for 
government. We must all involve our¬ 
selves in the broadest issues of our day, 
such as foreign affairs, the provision of 
health care, and the maintenance of our 
environment. All of these deserve your at¬ 
tention. Government needs your energy 
and your expertise. 


Norman Y. Mineta (D) represents Califor¬ 
nia's 13th Congressional District, located at the 
southern tip of San Francisco Bay. The district 
includes portions of San Jose and the Cities of 
Campbell, Los Gatos, and Santa Clara, as well 
as unincorporated parts of the County of Santa 
Clara. 

Born in 1931, Mineta was one of 110,000 
Americans of Japanese ancestry who were 
evacuated from the West Coast and placed in 
relocation camps during WWII. Attending 
schools in San Jose, he later graduated from 
UC Berkeley in 1953 with a BS in business, then 
served on active duty in the Army as an intelli¬ 
gence officer in Japan and Korea. 

Commencing his political career in 1962, 
Mineta served in a variety of local offices in¬ 
cluding membership on the San Jose City 
Council and mayor of San Jose. He has held a 
seat in Congress since 1974, serving on several 
major committees ranging from the Public 
Works and Transportation Committee to the 
Select Committee on Intelligence—posts he 
continues to hold today. Currently he is also a 
member of the House Committee on Science 
and Technology, where he serves on the Sub¬ 
committee on Space Science and Applications 
and the Subcommittee on Science, Research, 
and Technology. 


It is difficult to describe a micropro¬ 
cessor with only a few symbols. To in¬ 
tegrate more parameters, one should also 
indicate the size of the on-chip memory 
and the clock speed—one should call the 
Z80000 a “32/32 C256 K5” processor, 
for instance, since it has a multiplexed 
32-bit address and data path, a 256-byte 
cache, and a 5-MHz bus clock (which is 
more meaningful than the CPU clock). 
The 8051 would be a “17/8 R4K + M128 
K12,” since it has two address spaces, 4K 
of ROM plus 128 bytes of RAM, and a 
12-MHz bus clock. Such a method of de¬ 
scription would be rather cumbersome, 
of course. 

Hubert Kirrmann 
Brown, Boveri & Cie 
Research Center 
CH-5405 Baden, Switzerland 
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This driver enables easy implementation of the Am9511 as a coprocessor in Intel 

8085-based systems. 


An Efficient Software Driver 
for Am 9511 Arithmetic 
Processor Implementation 


Borivoje Furht, University of Miami 
Peter Lee, IBM, Corp. 


A n arithmetic processor unit interfaced to a host 
microprocessor system as a coprocessor significantly 
improves system performance, performing both a variety 
of fixed and floating point arithmetic operations and 
trigonometric and mathematical operations. An efficient 
software driver has been developed that enables easy 
implementation of the arithmetic processor unit (an 
Am9511 or Intel 8231 A) in a concurrent operation with a 
host microprocessor (e.g., Intel 8085). 

Basic hardware configuration 

The Am9511 arithmetic processing unit can be inter¬ 
faced to an Intel 8085/8086 host microprocessor just as 
any programmable I/O unit can. All transfers between the 
microprocessor and the arithmetic processing unit are per¬ 
formed using an 8 -bit directional data bus. Transfers to 
and from the APU are handled by using a conventional 
programmed I/O technique. To provide I/O mapped I/O 
an 8205 decoder is used to get the chip s elect to t he AP U 
with IO/M signal equal 1. The signals RD and WR are 
tied directly to the APU. Since the upper address lines 
(A 8 -A i 5 ) are non-multiplexed, they are used for selection 
of the APU. This technique relies on the fact that the I/O 
port number is copied onto Ag-A 15 as well as A 0 -A 7 dur¬ 
ing an input or output instruction. The basic hardware in¬ 
terface scheme is shown in Figure 1. 


The signal PAUSE from the APU is tied to the READY 
line of the 8085 to avoid data loss. This line is high in its in¬ 
itial state and is pulled low by the APU under the follow¬ 
ing conditions: 

• A previously initiated operation of the APU is in 
progress and a command entry is attempted. 

• A previously initiated operation of the APU is in pro¬ 
gress and stack access has been attempted. 

• The APU is not busy and data removal or data entry 
has been requested. 

Am9511 operation 

The Am9511 APU operation is based on commands 
supplied by a host microprocessor. Each command 
represents a single 8-bit datum, shown in Figure 2. 

• Bits 0-4 select the operation of the APU. 

• Bits 5-6 select the data format for the operation. If bit 
5 = 1, then a fixed-point datum is specified. If bit 
5 = 0, floating-point format is specified. Bit 6 selects 
the precision of the data. If bit 6 = 1 single precision 
(16 bits) is selected, while bit 6 = 0 selects double 
precision (32 bits). 

• Bit 7 indicates whether a service request is to be issued 
after the command is executed. If bit 7 = 1, a service 
request will be generated; if bit 7 = 0, a service re¬ 
quest will not be generated. 
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I/O ADDRESSES 
16H AND 17H 


Figure 1. Basic hardware interface. 
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OPERATION CODE 


Figure 2. Command format. 


A summary of the APU commands is given in Table 1. 
(In Table 1, TOS means top of stack and NOS means next 
of stack. In the hex-code column, SVREQ is a 0. 

The Am9511 APU is a stack-oriented processor, so the 
host processor has access to an eight-level, 16-bit-wide 
data stack. Single-precision fixed-point operands are 16 
bits wide, so eight such values may be stored in the stack 
(Figure 3a). When the data are double-precision fixed- 
point or floating-point operands (32 bits), the four values 
may be stored (Figure 3b). Data are written into the stack 
byte after byte, in the order shown in Figure 3 (Bl, B2, 
B3, . . . ). Data are removed from the stack in reverse 
order (B8, B7, B6, . . . ). 
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Execution times 

Timing for execution of the Am9511 commands is 
shown in Table 2. Speeds are given in terms of clock cycles 
and can be converted to microseconds by multiplying by 
the clock period used. Maximum clock frequency for the 
Am9511 is 2 MHz and for the Am9511-1 is 3 MHz. One 
version of the Intel 8231A is faster (4 MHz). 

interface strategies 

Two different interface techniques have been applied: 
pseudopolling and interrupt-driven interfaces. 


Pseudopolling interface technique. In this mode of 
operation the host processor sends one command after 
another to the APU using a standard output operation. 
Since a previously initiated operation will usually be in 
progress when a new command entry is attempted, the 
APU will pull the PAUSE line low, causing the host pro¬ 
cessor to skip into a waiting state. The PAUSE line will re¬ 
main low until completion of the current command execu¬ 
tion. It will then go high, permitting entry of the new com¬ 
mand. 

The software driver for the pseudopolling mode of 
operation (SDPPM) is simple and consists of a set of 
subroutines that send commands to the APU, have access 
to the APU stack, and remove/enter data from/to the 


Table 1. 

Command summary. 


COMMAND 


MNEMONIC 

COMMAND DESCRIPTION 

COMMAND CODE 

SADD 

FIXED POINT 16 BIT 

Add TOS to NOS. Result to NOS. Pop Stack. 

6C 

SSUB 

Subtract TOS from NOS. Result to NOS. Pop Stack. 

6D 

SMUL 

Multiply NOS by TOS. Lower half of result to NOS. Pop Stack. 

6E 

SMUU 

Multiply NOS ty TOS. Upper half of result to NOS. Pop Stack. 

7C 

SDIV 

Divide NOS by TOS. Result to NOS. Pop Stack. 

6F 

DADD 

FIXED POINT 32 BIT 

Add TOS to NOS. Result to NOS. Pop Stack. 

2C 

DSUB 

Subtract TOS from NOS. Result to NOS. Pop Stack. 

2D 

DMUL 

Multiply NOS by TOS. Lower half of result to NOS. Pop Stack. 

2E 

DMUU 

Multiply NOS by TOS. Upper half of result to NOS. Pop Stack. 

3C 

DDIV 

Divide NOS by TOS. Result to NOS. Pop Stack. 

2F 

FADD 

FLOATING POINT 32 BIT 

Add TOS to NOS. Result to NOS. Pop Stack. 

10 

FSUB 

Subtract TOS from NOS. Result to NOS. Pop Stack. 

11 

FMUL 

Multiply NOS by TOS. Result to NOS. Pop Stack. 

12 

FDIV 

Divide NOS by TOS. Result to NOS. Pop Stack. 

13 

SORT 

DERIVED FLOATING POINT FUNCTIONS 

Square Root of TOS. Result in TOS. 

01 

SIN 

Sine of TOS. Result in TOS. 

02 

COS 

Cosine of TOS. Result in TOS. 

03 

TAN 

Tangent of TOS. Result in TOS. 

04 

ASIN 

Inverse Sine of TOS. Result in TOS. 

05 

ACOS 

Inverse Cosine of TOS. Result in TOS. 

06 

ATAN 

Inverse Tangent of TOS. Result in TOS. 

07 

LOG 

Common Logarithm (base 10) of TOS. Result in TOS. 

08 

LN 

Natural Logarithm (base e) of TOS. Result in TOS. 

09 

EXP 

Exponential (e x ) of TOS. Result in TOS. 

0A 

PWR 

NOS raised to the power in TOS. Result in NOS. Pop Stack. 

0B 

NOP 

DATA MANIPULATION DEMANDS 

No Operation 

00 

F1XS 

Convert TOS from floating point to 16-bit fixed-point format. 

IF 

FIXD 

Convert TOS from floating point to 32-bit fixed-point format. 

IE 

FLTS 

Convert TOS from 16-bit fixed-point to floating-point format. 

ID 

FLTD 

Convert TOS from 32-bit fixed-point to floating-point format. 

1C 

CHSS 

Change sign of 16-bit fixed-point operand on TOS. 

74 

CHSD 

Change sign of 32-bit fixed-point operand on TOS. 

34 

CHSF 

Change sign of floating-point operand on TOS. 

15 

PTOS 

Push 16-bit fixed-point operand on TOS to NOS (Copy). 

77 

PTOD 

Push 32-bit fixed-point operand on TOS to NOS (Copy) 

37 

PTOF 

Push floating-point operand on TOS to NOS (Copy), 

17 

POPS 

Pop 16-bit fixed-point operand from TOS. NOS becomes TOS. 

78 

POPD 

Pop 32-bit fixed-point operand from TOS. NOS becomes TOS. 

08 

POPF 

Pop floating-point operand from TOS. NOS becomes TOS. 

38 

XCHS 

Exchange 16-bit fixed-point operands TOS and NOS. 

39 

XCHD 

Exchange 32-bit fixed-point operands TOS and NOS. 

39 

XCHF 

Exchange floating-point operands TOS and NOS. 

19 

PUPI 

Push floating-point constant " t " onto TOS. Previous TOS becomes NOS. 

1A 
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Table 2. 

Command execution times. 


COMMAND 

CLOCK 

COMMAND 

CLOCK 

MNEMONIC 

CYCLES 

MNEMONIC 

CYCLES 

SADD 


17 

SORT 

800 

SSUB 


30 

SIN 

4464 

SMUL 


84-94 

COS 

4118 

SMULI 


80-98 


SDIV 


84-94 

TAN 

5754 

DADD 


21 

ASIN 

7668 

DSUB 


38 

AC0S 

7734 

DMUL 


194-210 

ATAN 

6006 

DMUU 


182-218 

LOG 

4474-7132 

DDIV 


208 



FIXS 


92-216 

LN 

4298-6956 

FIXD 


100-346 

EXP 

3794-4876 

FLTS 


98-186 

PWR 

8290-12032 

FLTD 


98-378 



FADD 


54-368 

NOP 

4 

FSUB 


70-370 

CHSS 

23 

FMUL 


146-168 

CHSD 

27 

FDIV 


154-184 

CHSF 

18 

PTOS 


16 

P0PF 

12 

PTOD 


20 

XCHS 

18 

PTOF 


20 

XCHD 

26 

POPS 


10 

XCHF 

26 

POPD 


12 

PUPI 

16 


APU 

stack. The 

software driver SDPPM, 

written in 


assembly language for the 8085, requires 256 bytes of 


memory. 




A typical command routine for floating point 
multiplication is shown below: 


FMUL: MV1 A, 12H ; Code for multiplication 

OUT 17H ; Send command to the APU 

RET 


A typical entry routine ENT 16 for entering a 16-bit 
value into the APU stack has the following form: 

ENT16: MOV A, M 

OUT 16H ; Enter low byte 

INX H ; Increment pointer 

MOV A, M 

OUT 16 ; Enter high byte 

RET 

Before calling a routine for data entry/removal, the user 
should load the register pair H&L with the address of data. 

The user program is a simple sequence of CALL instruc¬ 
tions to the corresponding APU routines. 

Example 1. The following example illustrates the im¬ 
plementation of the SDPPM by a user program. Suppose 
the following computation should be performed as 

y = Vx-sinx 

where x is a 16-bit integer. 

Here is an efficient way to perform the desired function: 

• Load the 16-bit integer value of x in the APU. 

• Execute APU instruction FLTS to convert to floating 
point. 


• Execute APU instruction PTOF to duplicate the 
result of the floating-point conversion. 

• Execute APU instruction SIN to replace the value of 
x at the top of the stack with its sine. 

• Execute APU instruction FMUL to compute x-sinx. 

• Execute APU instruction SQRT to compute square 
root of x-sinx. 

• Finally, remove the result from the APU stack. 

The user program that performs the computation of y is 


the following sequence of CALL instructions: 

LXI H, XDATA 

; Pointer to x 

CALL ENT 16 

;Load 16-bit data into the APU 

CALL FLTS 

; Convert to floating point 

CALL PTOF 

; Duplicate x 

CALL SIN 

;Sin(x) 

CALL FMUL 

;x • sin(x) 

CALL SQRT 

;Square root of x-sin(x) 

LXI H, YDATA 

; Pointer to y 

CALL REM32 

; Remove 32-bit result from the 


APU 


The execution time analysis of the given example is shown 
in Figure 4. 

As can be seen from Figure 4, the microprocessor is in a 
waiting state during the operation of the APU, so a concur¬ 
rent operation of the ftP and the APU is not realized. 

Interru pt int erface technique. In this mode of operation, 
the signal END, generated by the APU, is used to activate an 
interrupt service routine in the ^ P. 

The host microprocessor, after preparing a set of com¬ 
mands and the corresponding data for the APU, is able to 
continue the execution of its own program. 

In order to enable a concurrent operation of the /rP and 
the APU, the following strategy, consisting of two steps, has 
been implemented. First, the user commands to the APU, 
given in a form of macroinstructions, are not executed 
directly but are temporarily stored in a command buffer in 
RAM. Also, the corresponding data are not entered directly 
onto the APU stack, but its addresses-pointers to the data are 
temporarily stored into a pointer buffer in RAM. The com¬ 
mand buffer is 20 bytes long, so the user can write an opera¬ 
tion consisting of a maximum of 20 APU commands. The 
data buffer is 10 bytes long, so five 16-bit pointers to the data 
can be stored in it. 

In the second step, at the end of a macro sequence, the user 
activates an interrupt service routine by using a CALL in¬ 
struction. The interrupt service routine coordinates the ex¬ 
ecution of the commands previously stored in the command 
buffer. Upon completion of each command from the com¬ 
mand buffer, the APU will issue an “end of execution 
signal” that will again activate the interrupt service routine. 
Then the ISR will send the next command from the com¬ 
mand buffer to the APU. 

Software driver for the interrupt mode. In defining soft¬ 
ware requirements for an APU software driver for the inter¬ 
rupt mode of operation (SDIM), the main objectives were 

• to make the use of the Am9511 easy, efficient, and flex¬ 
ible from the user’s point of view, and 

• to provide a concurrent operation of the host /zP and 
the APU. 
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Figure 4. Execution time analysis: pseudopolling technique. 


The designed software-driver SDIM consists of a set of 
macro definitions that perform all necessary data/com¬ 
mand preparation and an interrupt service routine that 
coordinates commands execution. 

Data entry/removal macros. There are two data-entry 
and two data-removal macroinstructions that initialize 
16-and 32-bit data transfer. These macroinstructions store 
the pointers to the data into the pointer buffer and an in¬ 
ternal code for the corresponding command (entry or 
removal) into the command buffer. 

For example, macroinstruction ENT16 DATAX stores 
the pointer to the data, with a symbolic address DATAX, 
into the pointer buffer, and the command 40H, that cor- 


responds to 16-bit data-entry into the command buffer. 
The macro definition for ENT 16 has the following for- 

mat: 



ENT 16 MACRO DATA 


LXI 

D, DATA 

; Pointer to the data . . . 

MOV 

M, E 


INX 

H 


MOV 

M, D 


INX 

H 

; . . . store into the PB 

MVI 

A, 40H 

;Code store into . . . 

STAX 

B 


INX 

ENDM 

B 

; ... the CB 

The internal codes 

for the entry/removal instructions are 


as follows: 

Instruction Hex Code 

ENT 16 40 


ENT32 

41 

REM16 

50 

REM32 

51 


Register pairs HL and BC are used as the pointers to the 
pointer buffer and the command buffer, respectively. In 
order to initialize any sequence of the APU operations, the 
user has to set these pointers to the top of the pointer buffer 
and the command buffer by usinj| the macroinstruction IN- 
IT at the beginning of an APU sequence. Also, the macro 
INIT clears the command buffer and the pointer buffer. The 
macro definition INIT has the following format: 

INIT MACRO PBUF.CBUF 


LXI 

H,PBUF 

;Clear the pointer buffer 

MVI 

D,10 


XRA 

A 


LOOP1: MOV 

M,A 


INX 

H 


INR 

D 


JNZ 

LOOP1 


LXI 

B,CBUF 

;Clear the command 
buffer 

MVI 

D,20 


LOOP2 STAX 

B 


INX 

B 


INR 

D 


JNZ 

LOOP2 


LXI 

H,PBUF 

;Pointer to the top of 
the pointer buffer 

LXI 

B,CBUF 

; Pointer to the top of 
the command buffer 


ENDM 
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Command entry macros. There are 42 command entry 
macro definitions that store the corresponding hex code 
(see Table 1) into the next available location of the com¬ 
mand buffer and then increment the pointer to the com¬ 
mand buffer. For example, macro definition FMUL for 
floating-point multiplications has the following format: 


FMUL MACRO 



MVI 

A,92H 

; Code for multiplication 

STAX 

B 

; Store code into the 
command buffer 

INX 

B 

; Increment pointer to 
the command buffer 

ENDM 




All the other APU commands have the same structure 
of macro definition. 


Interrupt service routine. The interrupt service routine 
coordinates the execution of the commands previously 
stored in the command buffer. The ISR also accomplishes 
data entry onto the APU stack and data-removal from the 
APU stack, using the pointers to the data previously 
stored in the pointer buffer. The current pointer to the 
data is always stored at the top of the pointer buffer, and 
the current command code is always stored at the top of 
the command buffer. After completion of a data entry, 
the current pointer will be removed and the next pointer 
from the pointer buffer will be shifted to the top of the 
pointer buffer. Similarly, after completion of a command 
entry to the APU, the command code from the command 
buffer will be shifted to the top of the command buffer. 
This avoids the necessity of saving pointers of the pointer 
buffer and the command buffer. 

The flowchart of the ISR is shown in Figure 5, and the 
corresponding program is given in the appendix. When the 
last command from an APU sequence has been com¬ 
pleted, the ISR will set an,“end of the APU sequence” flag 
in order to inform the main program of the completion of 
the whole APU operation. This flag can be at any location 
in memory. In the designated SDIM the flag is at the top 
location of the pointer buffer. 

Example 2. In order to illustrate the implementation of 
the SDIM, consider the same expression y = Jx-sinx 
given in Example 1. The user program is a sequence of 
macro references given below. At the beginning the user 
should reserve memory locations for the pointer buffer 
and command buffer. 


PBUF: 

CBIF: 

X: 

Y: 

START: 


Memory reservation 


DS 10 ; 

DS 20 ; 

DS 2 ; 

DS 4 ; 

The APU sequence 
INIT ; 

ENTI6 X ; 

FLTS ; 

PTOF ; 

SIN ; 


Pointer buffer 
Command buffer 
16-bit data 
32-bit result 
y = square root(x • sinx) 
Initialization 
Enter 16-bit data 
Convert to floating¬ 
point 

Duplicate X 
Sin x 


FMUL 
SQRT 
REM32 
CALL ISR 


x-sin x 

Square root of x-sin 
Remove 32-bit data 
Call interrupt service 
routine 

to activate the APU 
operation 


After execution of the whole sequence of macroinstruc¬ 
tions, the APU is not yet activated; however, the pointer 
buffer contains the pointers to the data x and y, and the 
command buffer contains the codes of the used APU com¬ 
mands, as shown in Figure 6. 

In order to compare the described interrupt-interface 
technique and the pseudopolling technique, the execution 
time analysis for Example 2 is shown in Figure 7. 

It is obvious from Figure 7 that the microprocessor is 
never in a waiting state, so the microprocessor and the 
APU operate concurrently. After preparing a set of APU 
commands and the corresponding data in the command 
buffer and the pointer buffer, the host microprocessor is 
able to continue the execution of its own program. 

In the case when microprocessor program needs a result 
from a previously activated APU sequence, it can test the 
“end of the APU sequence” flag set by the ISR at the end 
of an APU sequence. 


APU implementation in a mirltimicro- 
processor system 

In recent years the cost of microprocessor components 
has been reduced, so the concept of applying multiple pro¬ 
cessors to achieve better system performance, previously 
avoided, has now become an attractive and feasible design 
strategy. Since the cost of an APU is still high, however, 
including more than one APU in an MMP system would 
be very expensive. 

In this section we propose an MMP configuration with 
multiple processors that share a single APU. The APU 
software driver described can be used in this MMP system. 

A multiple master/dual bus multimicroprocessor ar¬ 
chitecture has been applied and described by Adams and 
Rolander. 4 Each processor-master has its own private 
memory and I/O. Access to the common bus occurs only 
when a master requires access to the common memory or 
common I/O. A parallel bus priority technique has been 
used which enables up to eight masters to run concurrent¬ 
ly. The control logic for the common bus access was 
designed using an Intel 8219 bus-controller. 

An Am9511 APU is a common I/O unit shared by all 
processors. The corresponding APU software drivers are 
the same for all processors and stored in their local 
memories. When a master requires an APU operation, it 
executes the corresponding APU driver from its local 
memory and activates the APU. 

After completing a single operation, the APU sends an 
interrupt signal to the corresponding master. 

The architecture of an MMP system with common APU 
is shown in Figure 8. Note that there needs to be additional 
logic to allow each processor select to either the local or 
common bus. Showing the details of the selection would 
make the figure complicated, so they are omitted. 
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Figure 5. The interrupt service routine. 


Two problems have to be solved in the MMP configura¬ 
tion. The first problem is mutual exclusion. It is necessary 
to assure that a master will have uninterrupted access to 
the APU. Therefore, a critical section of code has been in¬ 
troduced which, once begun, must complete its execution 


without interruption. This critical sequence has been con¬ 
trolled by using the hardware/software solution described 
below. The second problem is the interrupt signal, sent by 
the APU after cortipletion of its operation, that is interfac¬ 
ed to all the masters (Figure 8). In order to cause the ac- 
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Figure 6. The contents of the pointer buffer and the command buffer in Example 2. 



Figure 7. Execution time analysis: interrupt technique. 
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Figure 8. Multimicroprocessor system with a common APU. 


tivation of the interrupt routine in the master which had 
activated the APU, a software interrupt-mask technique 
should be used. 

The software driver SDIM, described in the previous 
section, can be easily extended in order to be used in the 
proposed MMP system with a common APU. First, a sub¬ 
routine TEST (see Figure 9) is introduced into the driver 


that controls the critical section of code and that solves the 
mutual exclusion problem. The routine TEST should be 
called by the user program after the preparation of the 
commands has been completed and before the execution 
of the ISR. 

Mutual exclusion is controlled by an “APU busy flag’’ 
in the common RAM memory set by the processor which 


June 1984 


15 































































































































































Figure 9. The routine TEST that controls the critical sec¬ 
tion of code. 


uses the APU, and using a hardware signal “Override” 
generated by the microprocessor through an output port. 
The override signal temporarily locks the access of the 
other processors to the common bus. 

Finally, the APU interrupt routine ICR should also be 
modified in order to be applied in the MMP system. The 
“APU busy” flag should be set at the beginning of the 
ISR, and the same bit should be reset at the end of an APU 
sequence. At the same time, the interrupt mask for 7.5 
should be set in order to disable the activation of the ISR in 
the processor. 

Example 3. A simple example illustrates the implemen¬ 
tation of the described software driver in an MMP system 
in which two microprocessors share an APU. 

Suppose that processor 1 (PI) should perform the 
following operation: 


x = a*b 

while processor 2 (P2) performs the following operation: 
y = c*d 


The user programs, stored in the local memories of PI 
and P2, are as follows: 


PROCESSOR 

1 

PROCESSOR 

2 

INIT 


INIT 


ENT 16 

A 

ENT 16 

C 

FLTS 


FLTS 


PLTD 


PLTD 


ENT16 

B 

ENT 16 

D 

FLTS 


FLTS 


FMUL 


FADD 


REM32 

X 

REM32 

Y 

CALL 

TEST 

CALL 

TEST 

CALL 

ISR 

CALL 

ISR 


Each microprocessor can be in one of the three possible 
states: 

• running state (RUN), executing its main program; 

• ISR-state, executing its interrupt APU service 
routine; 

• waiting state, when the APU is busy executing an 
APU sequence of another processor. 

The APU itself can be in either RUN or WAIT state. 
The timing diagram, shown in Figure 10, illustrates the 
operation of two processors that share an APU. 

• Suppose that at time t j processor 1 starts the execu¬ 
tion of an APU sequence, preparing the commands 
and the data. 

• At time t 2 , Pj has completed the execution of its 
macro sequence, storing all necessary commands and 
data into its command and pointer buffer, respective¬ 
ly. It executes the routine TEST and, since the APU is 
not busy, it starts the execution of the APU com¬ 
mands. Because of the use of this mutual exclusion 
technique, the access to the APU is inhibited for the 
other processors (in this example, for processor 2). 

• At time 1 3 processor 2 also starts the execution of its 
APU sequence, preparing the corresponding com¬ 
mands and data. 

• At time t 4 , P2 starts the execution of its TEST 
routine, testing the “APU busy” flag in the common 
memory. Since the APU is still busy executing the se¬ 
quence of PI, P2 starts the execution of a waiting 
loop, shown in Figure 9. 

• At time t 5 , the APU operation of PI has been com¬ 
pleted, so the ISR of PI will clear the “APU busy” 
flag in the CM. P2, which was in a waiting loop 
testing this flag, will obtain an access to the APU and 
will start the execution of its APU sequence. 

This analysis can be extended to the case when several 
processors share an APU. 


The APU software driver in a high-level 
language environment 

The APU software driver SDPPM can be easily 
modified and used in a high-level language environment. 

Intel’s 8085 Floating-Point Arithmetic Library contains 
basic floating-point subroutines and functions referred to 
as procedures. 6 The FPAL can be used by assembly 
language or PL/M programs. 
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ISR 


P, RUN 


WAIT 
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P, RUN 


WAIT 


MACROS 


FLTS 


PLTD 


FLTS 


ISR 


MACROS 


P 2 

JL 


FMUL 


FLTS 


PLTD 


FLTS 


FADD 


ISR 




TIME (jis) 


Figure 10. Timing diagram—MMP system. 


We have implemented the same strategy in designing an 
APU software driver to a high-level language, or SDHLL. 
A set of the procedures has been designed that use the 
APU to perform the arithmetic operations, instead of 
doing this by software routines. From the user’s point of 
view, the APU is invisible and the use of the SDHLL 
routines in a PL/M program is the same as the use of the 
FPAL routines. 

In general, the following steps should be observed to use 
the SDHLL: 

• An area of memory must be reserved for the floating¬ 
point record. 

• The names of the SDHLL procedures the user plans 
to use must be declared to be “external” using the 
EXTERNAL attribute in PL/M-80. 

• The SDHLL procedure references must be embedded 
in the user’s source code where appropriate. 

• The SDHLL procedure used by user’s program 
should be linked to the user’s object file. 

Example 4. The following PL/M example computes the 
function 

F=A*B+C 

where A, B, and C represent addresses of the floating¬ 
point numbers. F is the address where the result is to be 
stored, and FPR is the address of the floating-point 
register. 


We must first declare the SDHLL procedures used to be 
external and reserve the FPR memory as an array. The 
PL/M program is given below: 

/* EXAMPLE 4-F = A*B + CV 

/* — .V 

/* DEFINE EXTERNAL PROCEDURES V 
FSET: PROCEDURE (FA,0P1,0P2) EXTERNAL; 

DECLARE (FA,0P1,0P2) ADDRESS; 

END FSET; 

FADD: PROCEDURE (FA,0A) EXTERNAL; 

DECLARE (FA,0A) ADDRESS; 

END FADD; 

FMUL: PROCEDURE (FA.OA) EXTERNAL; 

DECLARE (FA,0A) ADDRESS; 

END FMUL; 

FLOAD: PROCEDURE (FA.OA) EXTERNAL; 

DECLARE (FA.OA) ADDRESS; 

END FLOAD; 

FSTOR: PROCEDURE (FA.OA) EXTERNAL; 

DECLARE (FA,0A) ADDRESS; 

END FSTOR; 

/* DECLARE BYTE ARRAYS V 
DECLARE FPR(18) BYTE, 

A(4) BYTE, 

B(4) BYTE, 

C(4) BYTE, 

F(4) BYTE; 
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Table 3. 

Execution times: SDHLL vs. FPAL. 


PROCEDURE 

AVERAGE EXECUTION 
TIME (MICROSECONDS) 
FPAL 

SDHLL 

FADD 

700 

30 

FSUB 

800 

35 

FMUL 

1500 

50 

FDIV 

3700 

57 


/* COMPUTATION OF F = A*B + C*/ 

/* FSET SHOULD BE CALLED FIRST V 


CALL FSET(.FPR,0,0); 

/•Initializa¬ 
tion of 
FPRV 

CALL FLOAD (,FPR,.A); 

/‘Load data 
A*/ 

CALL FMUL (.FPR..B); 

/•Multiply A 
and B*/ 

CALL FADD (,FPR,.C); 

/’Compute 
A*B* + C*/ 

CALL STOR (,FPR,.F); 

/‘Store 
result in F*/ 


The SDPPM driver can be modified in order to be con¬ 
sistent to the existing FPAL library package. A detailed 


description of the SDHLL is given by Furht and Milutino- 
vic . 7 

The existing PL/M programs, which use the FPAL 
routines, can implement the SDHLL routines without any 
change. In general, the only change occurs during the link¬ 
ing process. When the user has completed program 
development, he should link the SDHLL, instead of the 
FPAL, to his object modules. 

It is obvious that execution speeds of SDHLL pro¬ 
cedures are much faster than those of the corresponding 
FPAL procedures. Table 3 gives a brief comparison of the 
execution speeds of some commonly used procedures. The 
microprocessor clock frequency is supposed to be 6 MHz 
and the APU clock frequency is 3MHz. 

T hese software drivers enable easy and efficient APU 
implementation both in single microprocessor 
systems and in a multimicroprocessor system with a com¬ 
mon APU. Two different interface techniques have been 
used: pseudopolling and interrupt techniques. The cor¬ 
responding APU drivers have been developed—the 
SDPPM and the SDIM, respectively. The SDPPM can be 
modified for use in a high-level language environment. 
Using the APU driver, the user can focus attention on the 
problem by simply calling a set of macroinstructions or 
“CALL procedures” to activate the APU functions. 

The APU software driver could be included in a com¬ 
piler for a language such as PL/M, Pascal, or Ada.B 


Appendix: The Interrupt service routine of the SDIM 


. **********************************************,,, 


JZ 

ISR2 


; INTERRUPT SERVICE ROUTINE FOR SDIM 


INX 

H 


-RST 7.5 




INX 

D 




JMP 

ISR1 

; ... to the top 

First activation: CALL instruction from the main 




until 0 code is 


program at the end of an APU 




found 


sequence. 


ISR2: 

MOV 

A,B 

; Restore current 

Next activation: Interrupt signal END whenever 




command code 


a single APU operation has been 


ANI 

OFOH 

; Mask most 


completed. 





significant 4 

Function: 

Send a new command/data to 




bits 


the APU using the top of 


CPI 

40H 



command/pointer buffers. 


JZ 

ISR3 

; Test if data 

APU addresses: 16H - Enter/read byte into/from 




entry command 


the APU. 



CPI 

50H 



17H - Enter command/ read 


JZ 

ISR6 

; Test if data 


status 





removal 







command 

ISR: 

PUSH PSW 

; Save registers 

; Command entry to the APU 



PUSH B 



MOV 

A,B 

; Restore 


PUSH D 





command code 


PUSH H 



OUT 

17H 

; Send to the 

ISRO: 

LDA CBUF 

; Load next 




APU 



command from 


El 


; Enable 



the CB 




interrupt 


MOV B,A 

; Save command 


JMP 

ISR9 

; Jump to the 



in B 




end 


LXI H,CBUF 

; Pointer to the 

; Data entry to the APU 




top of the CB 

ISR3: 

LHLD 

PBUF 

; Address of the 


LXI D,CBUF + 1 

; Pointer to next 




first byte 



address 


MOV 

A,M 

; Send 1. byte 

ISR1: 

LDAX D 

; Shift codes in 


OUT 

16H 




the CB . . . 


INX 

H 

; Address of the 


MOV M,A 





second byte 


ORA A 



MOV 

A,M 

; Send 2. byte 
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OUT 

16H 



MOV 

A,B 

; Restore 
command code 


CPI 

41H 



JNZ 

ISR5 

; If 16-bit data 


1NX 

H 

; Address of the 
third byte 


MOV 

A,M 

; Send 3. byte 


OUT 

16H 



1NX 

H 

; Address of the 
third byte 


MOV 

A,M 

; Send 3. byte 


OUT 

16H 


ISR5: 

LXI 

B,CBUF 

; Shift pointers 
in the PB . . . 


LX I 

D,CBUF + 2 

; ... to the top 




until 0 pointer 
is found 

ISR5A: 

LDAX 

D 



STAX 

B 



MOV 

L,A 

; LSB of the 




address being 
moved 


INX 

D 



INX 

B 



LDAX 

D 



STAX 

B 



INX 

D 



INX 

B 



ORA 

L 

; MSB address is 
currently in A 


JNZ 

ISR5A 



JMP 

ISR0 

; Jump to “Load 
next 

command” 

Data removal from the APU stack in reverse order 

ISR6: 

LHLD 

PBUF 

; Address of the 
result in HL 


MOV 

A,B 

; Restore 
command word 


CPI 

51H 



JZ 

ISR7 

; If 32-bit result 


INX 

H 

; End of the 
16-bit data 
buffer 


IN 

16H 



MOV 

M,A 

; Store 1. byte 


DCX 

H 



IN 

16H 



MOV 

M,A 

; Store 2. byte 


JMP 

ISR8 


ISR7: 

INX 

H 



INX 

H 



INX 

H 

; End of 32-bit 
data buffer 


IN 

16H 



MOV 

M,A 

; Store 1. byte 


DCX 

H 



IN 

16H 



MOV 

M,A 

; Store 2. byte 


DCX 

H 



IN 

16H 



MOV 

M,A 

; Store 3. byte 


DCX 

H 



IN 

16H 



MOV 

M,A 

; Store 4. byte 

ISR8: 

MVI 

A,I 

: Set flag “End 
of APU 
operation” 


STA 

PBUF 



ISR9: POP H 

POP D 
POP B 
POP PSW 
RET 


; Restore 
registers 
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Don’t want to use an off-the-shelf system executive but lack the resources to develop one 
from scratch? This description will help you build your own custom package. 


A System Executive for Real- 
Time Microcomputer Programs 


Walter S. Heath 


T he availability of inexpensive microprocessors and 
support chips has proven to be a mixed blessing to the 
designers of electronic systems that must respond im¬ 
mediately to external events. On the one hand, systems 
that were previously implemented using customized, 
discrete logic may now be designed using a general- 
purpose microprocessor, thus reducing initial circuit 
design costs and improving the ability of the system to res¬ 
pond to subsequent design changes. Indeed, the flexibility 
of these devices has made possible the design of systems 
with logical complexities far exceeding those of earlier 
designs using discrete elements. 

On the other hand each new technological advance 
brings its own problems, and the microprocessor is no ex¬ 
ception. Designers of microprocessor-based systems have, 
no doubt, experienced the high costs and delays inherent 
in producing the software. The cost of producing custom¬ 
ized hardware logic has been replaced by the cost of pro¬ 
ducing custom software logic. This has not been a zero- 
sum game, however; the cost per logical operation has 
been reduced substantially. Rather, it is the sheer number 
and complexity of the logical operations performed in the 
software that has increased costs. In addition, the cost of 
maintaining the software as changes are made also in¬ 
creases as the initial structure of the program becomes lost 
in the changes. Clearly, if reasonably priced systems of in¬ 
creasing logical complexity are to be produced in the 
future, attention must continually be focused on methods 
for producing the software more efficiently. 


A traditional method for increasing software produc¬ 
tivity has been to use a high-level language, such as For¬ 
tran or Cobol. This approach has worked well for scien¬ 
tific and business programming applications where either 
the speed of execution could be sacrificed or large, fast 
computers could be used. Indeed, the relatively slow Basic 
interpreter may be credited with much of the success in ap¬ 
plying microcomputers to various data processing tasks. 
However, for applications in which speed of execution has 
been important, designers have had to remain with 
assembly language. This situation is changing for some ap¬ 
plications. 

As computer language designers develop new, struc¬ 
tured languages and efficient compilers, and as micropro¬ 
cessors are designed to support these new languages and 
run at faster clock-rates, it becomes more reasonable to 
consider using a high-level language in time-critical ap¬ 
plications. Indeed, the benefits may justify the use of 
multiple microprocessors running in parallel to achiever 
system timing requirements. Reduced initial software 
development and subsequent maintenance costs can be 
considerable. 

Another way to improve software productivity and run¬ 
time efficiency is to provide an “environment” within 
which application programs may be executed in an effi¬ 
cient and timely manner. In real-time systems this en¬ 
vironment is usually called a “system executive” and the 
application programs are referred to as “tasks” (or pro¬ 
cesses). The system executive is generally responsible for 
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making sure application tasks are executed at the proper 
times and for providing a formal means for tasks to com¬ 
municate with each other. 

Tasks must also be able to communicate with the out¬ 
side world. An input/output device may be serviced by 
polling it periodically and testing its status or by allowing it 
to cause an interrupt. Polling, however, wastes computer 
processing time and introduces delays. For time-critical 
applications this approach is therefore generally inade¬ 
quate. When a device causes an interrupt, the processor 
saves the address of the next instruction in the program 
currently running and transfers control to an interrupt 
handler program (sometimes called a device driver) to ser¬ 
vice the interrupt. Usually data are read from or written to 
the device before control is returned to the interrupted 
program. Data are passed between interrupt handlers and 
tasks using the communications services provided by the 
system executive. Some system executives provide I/O 
device drivers; others require the user to write them. The 
advantage of user-written drivers is that they may be effi¬ 
ciently tailored to the specific needs of the application. 

A clearly defined, efficient system executive provides a 
“skeleton” upon which an application program may be 
built. It separates program control and communication 
functions from application-dependent operations. Thus, 
the two aspects of a real-time program may be designed 
and maintained independently. A well-designed system ex¬ 
ecutive should require few changes over the life of a pro¬ 
gram. By contrast, application tasks will probably 
undergo considerable change. This separation reduces the 
possibility of application changes obscuring or disrupting 
the basic structures of the program as a whole. 

The designer has a number of options available in select¬ 
ing a system executive. Standard executives may be pur¬ 
chased in the form of a software package or a firmware 
ROM chip. The primary advantages of this approach are 
the possibility of immediate cost savings and the elimina¬ 
tion of in-house program development delays. A possible 
disadvantage is the designer’s lack of knowledge and con¬ 
trol over the operations performed within the executive. A 
standard executive must be designed to satisfy the re¬ 
quirements of a large class of applications. 

The alternative approach is to define and write a custom 
executive tailored to the needs of the specific application. 
In this way the designer can optimize executive perfor¬ 
mance as the project evolves. This approach makes sense 
for systems in which timing constraints are either not well 
understood or else cannot be predicted in the early stages 
of the project. It is also a good choice for systems that are 
likely to undergo substantial modification over their 
lifespans. 

The prospect of having to design and implement a com¬ 
plete system executive can be unsettling to a project leader 
who is faced with a deadline and limited resources. He 
must assess the size of the effort involved before the 
make/buy decision is made. The minimal system executive 
described here has been successfully implemented; hence it 
may serve as the basis for the specification of an executive 
program package. The material presented here may also 
be used to estimate the effort required to produce this 
component of a real-time program. 


The system executive consists of two major compon¬ 
ents: a task scheduler and a set of message queue access 
functions. The scheduler initiates application tasks on a 
priority basis in response to wakeups from interrupt- 
handlers and other tasks. Messages are passed between 
tasks and between interrupt-handlers and tasks by means 
of circular queues. The queue-access functions provide 
standardized access to these queues. 

This particular implementation uses the C language and 
a target Z80 microprocessor so that specific design details 
can be discussed. However, the concepts presented should 
be applicable to systems using other languages and/or pro¬ 
cessors. The C language has been found to be particularly 
suited to the needs of real-time systems. It might be con¬ 
sidered to be an intermediate level language that combines 
the expressive power of a high-level language with the 
ability to access memory locations directly, a characteristic 
of assembly language. The particular C compiler used also 
provides for in-line machine code for situations that re¬ 
quire direct control of hardware resources. With both the 
system executive and the application functions written in 
C, the entire microprocessor program may be linked into 
one module. This simplifies the interface between the two 
program components. 

Scheduler 

Task-scheduler designs may be grouped into two 
general categories: preemptive and non-preemptive. A 
task running under a preemptive scheduler may be 
suspended if a task of higher priority is awakened by an in¬ 
terrupt handler. This is important for systems in which 
data received by an interrupt handler must be processed 
immediately by a task awakened by that handler. Preemp¬ 
tive scheduling may also be necessary if the data rate is 
such that there is the possibility of data being overwritten 
before it can be processed. This problem can sometimes be 
solved by double-buffering the data in either hardware or 
software. 

By contrast, a task running under a nonpreemptive 
scheduler may not be preempted (that is, suspended) even 
though a task of higher priority is awakened. Except for 
interrupt servicing, the running task has control of the 
computer until it suspends itself. In systems using non¬ 
preemptive scheduling it is necessary for tasks to cooperate 
in using processor bandwidth by limiting the amount of 
processing performed between voluntary suspensions. 
This is not a serious limitation in many real-time applica¬ 
tions in which timing requirements are not critical. A 
significant advantage is that it considerably simplifies the 
scheduler design and therefore reduces memory and 
execution-time requirements. 

Another major advantage of nonpreemptive scheduling 
is that it reduces the possibility of inconsistent data being 
passed between program components. Presumably, a task 
will complete the processing of an entire message before 
voluntarily suspending itself. By constrast, a task running 
under a preemptive scheduler may have processed part of 
the data in a message when an interrupt handler causes a 
higher priority task to run. This task might change the 
content of the message that was being processed by the 
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Figure 1. Task control block data structure. 



Figure 2. Task Status. 


original task. A data access lockout mechanism must be 
implemented to avoid this problem.* 

An objective of this design was to keep the scheduler as 
simple as possible so that executive execution-time over¬ 
head would be minimized. In addition, the anticipated ap- 


’The use of queues to pass data between program components also reduces 
the possibility of inconsistent data, since new data do not overwrite old data 
until the space has been released. 


plications did not require the immediate processing of data 
received from interrupt handlers. As a result, a non- 
preemptive type scheduler was chosen. 

Task control. The status of each task is maintained in a 
task control block. The TCBs for all application tasks are 
contained in a linked list data structure, as shown in Figure 
1. A TCB contains a forward-link pointer, used by the 
scheduler to access TCBs, the starting address of the task, 
the task’s current stack-pointer, and “status” and 
“signal” flags. 

A linked-list data structure is used for the TCB data area 
primarily for the purpose of determining task priority and 
to facilitate scheduler operations. When a task suspends 
itself the scheduler always starts checking TCBs at the 
beginning of the linked list. As a result, the task described 
by this TCB has highest priority. Scheduler operations are 
also facilitated by linking the lowest priority TCB to the 
highest. Then, during periods when no tasks are sched¬ 
uled, the scheduler simply searches continuously through 
the TCBs. Note that this will be the normal idle condition 
for the task scheduler unless a lowest priority idle task is 
defined. The idle task must pause periodically to allow 
higher priority tasks to run. 

The linked-list data structure for TCBs is also con¬ 
venient for systems in which tasks install other tasks to run 
or in situations in which task priorities must be changed 
dynamically. The forward-link pointers may simply be 
changed to reorder the list. 

A task may be in one of three states: running, waiting, 
or ready, as shown in Figure 2. Its current state is deter¬ 
mined by the values of its “status” and “signal” flags. A 
task’s state may be changed by calling one of the three 
functions: run(), sleepf), or wake(). Note that the 
“signal” flag for a RUNNING task may be in one of two 
states. This means that a RUNNING task may also be in 
the READY state. This situation can occur when a RUN¬ 
NING task is interrupted and scheduled to run again. 
More will be said about this later. 

The scheduler and each task maintain their own stack 
areas. When a task is interrupted or suspended, its context 
(that is, the processor’s registers and flags) is stored on its 
stack. Similarly, when the scheduler transfers control to a 
task, the scheduler’s context is stored on its stack. The 
context is restored when control is returned to the task or 
scheduler. When a high-level language is used, the sched¬ 
uler may use the stack area originally allocated by the com¬ 
piler; task stacks must be explicitly declared as data areas 
in the program. 

When a task is invoked, the scheduler’s stack pointer is 
saved in a memory location. The task’s stack pointer is 
then read from its TCB and loaded into the Z80’s SP 
register. When a task is suspended, the reverse operation is 
performed. On the other hand, when an interrupt occurs, 
the context of the running program (task or scheduler) is 
saved on its stack, but the interrupt handler uses the run¬ 
ning program’s stack for its operations. It must, of course, 
pop off all data that it pushes onto this stack before re¬ 
turning to the interrupted program. Interrupts are dis¬ 
abled while the handler is saving and restoring the inter¬ 
rupted program’s context. However, they may be enabled 
while it is performing other operations, since subsequent 
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interrupt handlers will merely stack the context of the 
handler they interrupted. 

A task program has the general structure shown in 
Figure 3. It is a C function containing an “infinite” loop. 
During program startup each task is run from its begin¬ 
ning to the point where it first suspends itself by calling 
sleep(). During this time the task may perform any task- 
specific initial setup operations. This would include the in¬ 
itialization of any data items that do not have to be 
reinitialized during a restart (restart is performed by an in¬ 
itialization task which will be described later). After start¬ 
up, task entry and exit operations are performed entirely 
within sleep( ). 

Scheduler functional components. The scheduler is 
composed of four basic functions: sched(), wake(), 
run(), and sleep(). Their relationships to task states are 
shown in Figure 4. Each is a C function; some contain 
machine code. 

After initialization, the scheduler scans TCBs until it 
finds one with a “status” flag set. It then clears the corre¬ 
sponding “signal” flag and calls run(); run() transfers 
control to the previously suspended task and resumes task 
operation at the point where suspension occurred. 

A task suspends itself by calling sleep! ). This function 
clears the task’s “status” flag and transfers control back 


( tasknQ ~) 


PERFORM TASK-SPECIFIC 
INITIAL SETUP 
OPERATIONS 


CALL sleep)) 


TASK APPLICATION 
OPERATIONS 


Figure 3. Task program structure. 



Figure 4. Task states and state change mechanisms. 

June 1984 


23 






















































































Language features 

Features of C referred to in the main article will be briefly 
described here for those unfamiliar with the language. Readers 
interested in a complete description of the language should refer 
to Kernighan and Ritchie.* 

Structured code. C is a structured language. That is, the pro¬ 
grammer is provided with a set of programming “constructs” 
from which to build a program. For example, the “for” statement 

for ((i =0; i<10; i+ + )(...) 

will perform all statements within the braces 10 times. Index i is 
initialized before the statements are executed the first time; i is 
incremented and tested after each execution. 

An “infinite” loop may be programmed as follows: 

for(; ;)[ 
sleep() ; 


The statements within braces will be performed “forever.” The 
example represents the basic structure of an application task. 
Entry and exit from the loop are actually performed within the 
sleep() function. 

Structured data. C provides certain predefined data types, 
such as “int” for words (16 bits) and “char” for bytes (8 bits). It 
also provides mechanisms for the declaration of application- 
specific data types and structures. The following “typedef” 
structure declares a data type “QUE”: 

typedef struct( 

int head ; 

int tail ; 

int length ; 

char task ; 

char *pbuf ; 

JQUE 

A variable may then be declared to have type QUE: 

QUE timkey ; 

Physically, timkey contains 9 bytes: 6 for the three “int” variables, 
1 for the “char task” variable, and two for “char *pbuf.” Notation 
*pbuf specifies that pbuf is a pointer (16 bits) to a “char” variable. 
Thus, if pbuf is incremented, it will be advanced by one byte posi¬ 
tion. It is, in fact, the address of a data item. Thus it may be in¬ 
itialized to point to the first location in array tkbuf[ ] as follows: 

timkey.pbuf = &tkbuf[0] ; 

This statement shows that a variable within timkey may be 
referenced using the “.” notation. It also illustrates the use of “&” 
to indicate the address of an item of data. 

Recall that a memory location has two number associated with 
it: its address and its contents. C allows a variable name to be 
declared to represent either number and a means to reference the 
other. Thus, if pointer (address) pbuf is declared, then the value 
(content) of the location pointed to is *pbuf. Alternatively, if data 
array tkbuf[] is declared, then the address of element zero is 


&tkbuf[0]. This feature of C gives the programmer direct access 
to computer memory locations. 

The items within structure timkey may be initialized as follows: 

QUE timkey = (0,0,TKLNGTH,0] ; 
where TKLNGTH is defined using 

#define TKLNGTH 6 

In this context, #define is called a “macro substitution,” which 
simply means that the compiler will substitute “6” whenever it 
encounters TKLNGTH in the source program. 

For programs consisting of many files in which the QUE data 
type is used, it is convenient to place the declaration in a separate 
file. The file may then be included in each application file at com¬ 
pile time if a statement such as 

#include xxx.h 

is included, where xxx.h is the file containing QUE. 

Finally, if a program in one file wishes to reference variable 
timkey declared in another file, it may do so if it first declares 
timkey to be external: 

extern QUE timkey ; 

and if timkey has been defined to be a global variable in another 
file. The external reference will be resolved when the compiled 
object files are linked together. 

One may also declare a local data structure without using 
typedef. For example, a task-control block data structure might 
have the following form: 

struc( 

int tsklnk ; 

int *tskadr ; 

int tsksp ; 

char tsksta ; 

char tsksig ; 

Jtcb[NTSKS] 

This is an array of “NTSKS” tcb structures. 

Function entry/exit protocols. When a C function is called, the 
compiler must provide a means for passing arguments to the 
function. Most compilers accomplish this by calling an internal 
(C library) function-entry subroutine. The subroutine constructs a 
“frame,” or region, on the currently active stack to hold the func¬ 
tion arguments. In addition, stack space may also be reserved for 
certain temporary variables declared within the function body 
(see the description of re-entrancy). A frame-pointer register is 
set to point to the frame. The compiler then uses offsets from the 
pointer to reference data. 

Similarly, on exit from a function, the compiler calls a function- 
exit protocol subroutine, which restores the stack to the condi¬ 
tion it was in before the function was called. 

It is these entry/exit protocol subroutine calls that must be 
bypassed on entry and exit from an interrupt handler. If they are 
not, the context of the interrupted program will be lost before it 
can be pushed on the stack on entry and restored on exit. 

To provide support for high-level languages, some of the new 
16-bit microprocessors have implemented these entry/exit pro¬ 
tocols in firmware. 

* The C Programming Language, Brian W. Kernighan and Dennis M. Ritchie, 
Prentice-Hall, Inc., Englewood Cliffs, NJ 07632. 
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to the scheduler. However, it first checks the “signal” 
flag. If the signal flag is set, it means that the RUNNING 
task was also READY, indicating that an interrupt oc¬ 
curred while the task was running and the interrupt 
handler rescheduled the running task to run again. The 
sleep() function handles this situation by resetting the 
task’s state to READY (by setting the “status” flag) and 
returning control to the scheduler. The scheduler then 
scans TCBs, starting at the highest priority, until it finds a 
READY task and invokes it.* 

A task may be awakened from the WAITING state by 
calling wake(). This function’s single argument specifies 
the number of the task to be awakened. It. is used as an 
index into the array of TCBs. The wake() function sets the 
task’s “status” and “signal” flags. These are the only 
operations performed by wake; it is written entirely in C. 
The wake( ) function may be called either from an inter¬ 
rupt handler or from a task. 


*The order in which the operations are performed in sleep( ) is important. 
For example, it would appear that STATUS could be reset after the 
SIGNAL test, when the SIGNAL test fails. However, if an interrupt occurs 
between the test and the reset, then STATUS and SIGNAL will both be set 
(if the interrupt handler reschedules the running task). Then, when 
STATUS is reset after returning from the interrupt, the final state will be 
STATUS = 0, SIGNAL = 1, which is a disallowed state. Programming 
sleep( ) as shown will avoid this problem. 


One additional scheduler program component is the 
pause() function. It was not included as a “basic” func¬ 
tion since it can be constructed from the wake() and 
sleep( ) functions. It provides a means for a task to give 
processor control back to the scheduler voluntarily but, 
before doing so, reschedule itself to run again. This gives 
higher-priority tasks that may have been awakened by in¬ 
terrupt handlers a chance to run before the pausing task 
resumes. The pause( ) function may be implemented sim¬ 
ply as a C function that calls wake() and then sleep(). The 
task number needed as an argument in the call to wake() 
may be supplied either as an argument in the pause)) call 
or, since the number of the currently running task is 
known to the scheduler, it may be supplied automatically. 

Scheduler initialization. All C programs start at the 
beginning of the function called main( ). In this applica¬ 
tion main() performs initial startup operations that do not 
have to be performed during a program-controlled restart. 

One operation performed by main) ) is to initialize 
run) ) and sleep) ), as shown in Figure 5, by computing 
addresses RUNADR and SLPADR, respectively, These 
addresses are needed when control is passed between 
run) ) and sleep) ) during invocation and suspension of a 
task, as will be explained later. Since these addresses will 
be referenced from outside their respective functions, they 



runint = 0 
COMPUTE ADDRESS 
RUNADR: 


I 

MAIN BODY 
OF run)): 

RUNADR: 

-► 

( RETURN ) 



slpint = 0 
COMPUTE ADDRESS 
SLPADR: 


MAIN BODY 
OF SLEEP)): 

SLPADR: 

-► 

( RETURN 


Figure 5. Computing return addresses: RUNADR, SLPADR. 
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Definitions 


These definitions briefly describe term usage within the con¬ 
text of this article. They are not intended to be universal. 

Real-time system. This term refers to the response-time of a 
system to external events. Its use is highly context-dependent. 
Some systems require response times in microseconds or less to 
perform properly (e.g., certain feedback control systems). 
Systems that supply responses comparable to human reaction 
times (seconds) are also considered real-time. The term is used to 
distinguish such systems from data processing or computation¬ 
intensive systems in which response times are not the central 
concern. 

System executive. A system executive is a collection of func¬ 
tions that provides program initiation and data communication 
services to application programs. It provides an environment 
within which a collection of application programs may be 
operated. Application programs constitute “’tasks” which are run 
by the executive in response to requests from other tasks or ex¬ 
ternal events. In the case of an external event, a signal (or inter¬ 
rupt) is processed by an “interrupt handler” program which posts 
a request to the executive for a particular task to be run. This ac¬ 
tion constitutes a “wakeup” or “scheduling” of the task. System 
executives sometimes provide standard “device drivers” for 
common I/O devices (e.g., consoles, printers, etc.). These take the 
place of user-written interrupt handlers and may be much more 
complex and general purpose. 

Application tasks may be assigned priorities. The executive’s 
“scheduler” will then choose the highest priority scheduled task 
to run next. 

Application tasks may pass data, or “messages,” by calling ex¬ 
ecutive service routines. These routines maintain message 
“’queues” (sometimes called “mail boxes”) to store and forward 
messages between tasks and between tasks and interrupt 
handlers (or device drivers). 

System executives are sometimes confused with operating 
systems. An operating system may contain a system executive 
but is usually much larger and provides many more services, 
such as program development tools and disk management 
utilities. 

Data structures. Data structures are programming techniques 
for organizing data so that they may be accessed and updated in 
an efficient and orderly manner. A variety of data structures have 
been devised. Each solves a particular data organization problem. 

The “queue” data structure is used to control the flow of 
messages between two asynchronously running programs or 
tasks. A data queue is analogous to a queue of people waiting to 
enter a movie. New entries are added at the “tail”; old entries are 
removed at the “head.” However, the queue of people moves for¬ 
ward when “entries” are removed from the head. In a data queue, 
it would be inefficient to move all the data forward each time an 
entry is removed. Instead, pointers are maintained indicating the 
next entry to be removed at the head and the next open entry at 
the tail. Obviously, as entries are added to the tail, a point is 
reached when no more room exists in the memory region set 
aside for the queue. The next entry added must then be “wrapped 
around” and placed at the beginning of the queue, if sufficient 
space has been vacated by removal of entries from the head. If 
the queue is full, the requesting program must be told that the 
operation has failed. A queue in which entries are wrapped is 
referred to as a “circular queue.” 


Another method for passing data between asynchronously 
running programs is to “buffer” the data. In this method, one or 
more buffers (blocks of memory) are set aside to hold messages. 
A scheme is then devised to place new messages in empty buf¬ 
fers and remove messages from full buffers. This method is often 
used between interrupt handlers and tasks, if the data are re¬ 
ceived in bursts. The data may be buffered and then processed by 
the task over a period when the interrupt handler is dormant. Data 
buffering may be performed in hardware or software, depending 
on timing requirements. 

Another type of data structure is the linked list. This technique 
is generally used to maintain a list for sequential processing in 
which the structure of the list may have to be revised dynamically 
(i.e., during program execution). Entries may have to be added or 
removed; the list may have to be reordered. 

Linked lists are maintained by means of pointers. Each entry 
contains a pointer (address or index) to the next entry in the list. 
Sometimes both forward and backward pointers are maintained 
so that the list may be searched in either direction. Entries in the 
list may be reordered or removed or new entries may be added by 
manipulating the pointers. The task control blocks described in 
this article are organized as a linked list so that they may be 
searched in a user-specified, priority order. 

Processor bandwidth. This term borrows from the vocabulary 
used in analog circuits. A processor’s bandwidth is its instruc¬ 
tion execution rate, expressed in instructions per second. When 
an operation uses too much of the processor’s execution time, it 
is said to be using too much “processor bandwidth.” 

Access lockout. When more than one asynchronously running 
program must access a common data region, a mechanism must 
be provided to ensure exclusive access. Otherwise the data in the 
region may become corrupted. For example, one task might copy 
a record (collection of data items) out of a common region, 
change an item in the record, and write it back. However, without 
a “lockout mechanism,” another task may read the same record, 
change an item, and write the record back before the first task 
has completed its operation. The change made by the second 
task will be overwritten by the record written back in by the first 
task. The solution is to provide an access “gate” (also called a 
semaphore) that must be tested to receive access (see the sec¬ 
tion on re-entrancy for a discussion of semaphores). 

Context. The context of a running program is the collection of 
all data that describe the current state of execution of the pro¬ 
gram. Physically, in a microprocessor system, it consists of the 
contents of the internal processor registers, including the pro¬ 
gram counter, and flags register. This context may be saved on 
the stack, and the processor may perform some other operation. 
The context may then be restored and the original program 
resumed, as if no interruption had occurred. 

The term “state” is sometimes used in place of “context.” 
However, in this article, the term is used to describe the status of 
a task. 

Interrupt vector. When a device interrupts a processor, it usual¬ 
ly provides an identification byte indicating the interrupt source. 
This byte is used by the processor to find the address of the ap¬ 
propriate interrupt handler program. The address is called an “in¬ 
terrupt vector.” 
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Figure 6. Task initialization. 


must be computed and treated as global data items. As 
mentioned earlier, each task must be called and run to the 
point at which it first suspends itself. This operation is 
diagrammed in Figure 6. In main(), return address 
STRADR is computed and stored in variable “rtnadr.” It 
is used as a return address by sleep() during task initializa¬ 
tion operations. Then main() saves its stack pointer and 
gets the stack pointer for the first application task [in the 
figure, taskn() represents “task «”] from its TCB. It then 
calls the task using a normal C function call operation. 
The task initializes startup data, as described earlier, and 
suspends by calling sleep(). Function sleep( ) saves the 
task’s stack pointer in its TCB and passes control back to 
main() via the address in “rtnadr.” Function main( )then 
restores its stack pointer and repeats the entire sequence of 
operations for each application task. At this point 
sleep( )’s return address, “rtnadr,” is switched to 
RUNADR, the entry point in run(). During all future 
operations sleep() will return to this point. 


Scheduler operation. After initialization, scheduler 
operation proceeds as diagrammed in Figure 7. Function 
sched() scans TCBs, starting at the beginning of the linked 
list, until one is found in which the “status” flag is set. It 
then stores the address of the selected TCB in variable 
“tcbadr” and calls run(). The run() function saves the 
scheduler’s context by switching to the second set of 
registers provided by the Z80 (it also pushes registers IX 
and IY on its stack).* It then saves the current stack 
pointer and transfers control to address SLPADR in 
sleep(). The sleep() function gets the stack pointer from 
the TCB pointed to by “tcbadr” and places it in the Z80’s 
SP register. It then restores the task’s context from its 
stack and returns to the task by means of the normal C 


*If the second register bank is needed for some other purpose, the 
scheduler’s entire context may be saved on its stack. For example, the sec¬ 
ond register bank could be used to save context in an interrupt handler and 
thereby minimize its execution time. 
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function return protocol. This is possible since the return 
address was pushed on the stack when the task was initially 
run to its first call to sleep( ), as described earlier. 

At this point the task proceeds to perform application 
operations until it again calls sleep( ). As shown in Figure 
7, after sleep( ) clears the “status” flag it checks the 
“signal” flag. If it is set it proceeds, as decribed earlier, to 
reschedule the task. In either case it then saves the task’s 
context on its stack, stores the task’s stack pointer in its 
TCB, and transfers control to address RUNADR in 
run(). The run() function then restores the scheduler’s 
stack pointer and its context and returns to the scheduler 
via the normal C return protocol. The scheduler then starts 
at the top of the TCB linked list and scans for another task 
to run. 

Note that as far as the task is concerned, its call to 
sleep( ) and the return were just the same as any other C 
function call. It is not “aware” of the fact that sleep() 
transferred control back to the scheduler and that other 
tasks possibly ran before sleep() returned. The same is 
true of sched( ) and its call to run( ). The scheduler is not 
“aware’ ’ that run( ) transfers control to a task and receives 


control back before returning. It is therefore unnecessary 
for the person writing an application task to know the 
operational details of the task scheduler; he simply pro¬ 
grams a call to sleep( ) to cause a suspension and expects 
the task to be awakened at the next C instruction. 

Programming interrupt handlers is somewhat more 
complicated. First, the context of the interrupted function 
must be saved on the currently active stack. This is per¬ 
formed using PUSH instructions in machine code. After 
performing I/O operations the context is POPped off the 
stack and control is returned to the interrupted function. 

The interrupt handler is written as a normal C function 
(with in-line machine code). However, it is not entered or 
exited using the normal C protocol. Instead, the-interrupt 
vector is computed so that the First instruction performed 
is the first PUSH of the context-save sequence. This 
bypasses the normal C function entry sequence. It is 
necessary to save the context before any other operations 
occur so that the interrupted program’s context will not be 
lost. Similarly, control is transferred back to the inter¬ 
rupted program with a normal Z80 return-from-interrupt 
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instruction just after the context has been POPped from 
the stack, bypassing the normal C function exit sequence. 

An interesting observation can now be made concerning 
this particular implementation of a task scheduler. It has 
not been necessary for the implementer to be aware of the 
details of the C function entry or exit protocols used by the 
compiler. In interrupt handlers, they are simply bypassed. 
The running program’s context (machine state) is saved, 
interrupt operations are performed, the context is 
restored, and control is returned to the running task before 
the handler’s normal C function return operations. Sim¬ 
ilarly, transfers between the scheduler and tasks are per¬ 
formed within C functions run() and sleep(). These func¬ 
tions save machine context on the currently active stack, 
transfer control, and restore the context of the destination 
function from its stack. In this way task scheduling and in¬ 
terrupt operations are transparent to the compiler. The C 
program’s context is saved before these operations are per¬ 
formed and restored afterward. 


Queues 

The other aspect of real-time program design involves 
the implementation of a means for passing data between 
tasks and between interrupt handlers and tasks. Since 
tasks and interrupt handlers run asynchronously, the use 
of queues for these operations ensures that messages will 
not be lost. 

Queue design considerations. One must first decide 
whether the application requires fixed- or variable-entry 
size queues. Fixed-entry size queues are easier to imple¬ 
ment since no wrap-around problem exists at the end of 
the queue. In addition, the entry size does not have to be 
included as part of each entry; it can be placed in the queue 
header. If variable-length queue entries are required, one 
must decide whether to wrap an entry at the end of the 
queue or to simply abandon the space at the end and start 
the new entry at the top. The decision should be based on 
expected queue entry sizes. This will determine the average 
amount of space that will be wasted at the end of the 
queue. The tradeoffs, as usual, are between extra process¬ 
ing time and extra memory space. 

Queue structures. Within C it is possible to define a 
queue header structure data type by using a “typedef” 
declaration. For a variable entry size queue, this might 
take the following form: 

typedef struct [ 

int head ; 

int tail ; 

int length ; 

char task ; 

char * pbuf ; 

]QUE 

This declaration may be placed in an “include 11 file that is 
attached to each program source file. Entries are added to 
the queue starting at the “tail” pointer and removed start¬ 
ing at the “head.” The queue’s length is specified by 


parameter “length.” The parameter “task” will be 
described in more detail later in the discussion of queue ac¬ 
cess functions. Briefly, it contains the number of a task 
that suspended itself when it was not able to complete a re¬ 
quested queue-access operation. Pointer “pbuf” points to 
the beginning of the actual queue data array. The first byte 
in each queue entry contains the number of bytes that 
follow in that entry. 

Using the QUE data type it is then possible to define 
queues and their headers as follows: 

#define TKLNGTH = 6 

QUE timkey = {0,0,TKLNGTH,0) ; 

char tkbuf[TKLNGTH] ; 

This might define, for example, a queue for passing data 
between a timer task and a keyboard task. The pointer 
“pbuf” to the queue array tkbufi ] must be initialized to 
the address of the array with a statement of the following 
form: 

timkey. pbuf = &tkbuf[0] ; 

This queue may be referenced from the file containing 
the timer or keyboard task by first declaring the queue 
header as an external reference: 

extern QUE timkey ; 

and then by referring to its address, &timkey, in, for ex¬ 
ample, the argument list of a queue access function. 

Queue access functions. Various queue-access functions 
may be written to satisfy different application require¬ 
ments. These functions may be built upon two primitive 
functions which will be called putq() and getq(). 

The putq() function declaration has the form 

putq(source, dest, count) 

where “source” is a pointer to an array (or item) of data to 
be placed in the queue and “dest” is a pointer to the queue 
header. The “count ’ ’ function is the length of the message 
to be moved, in bytes. For example, this function could be 
used to move a four-byte message from array gmttim[ ] in 
the timer task to the keyboard task by writing 

if (putq(gmttim, &timkey, 4) = = - 1) 
sleep() ; 

As indicated, putq( ) is programmed to return a - 1 value 
if not enough room exists in the specified queue to store a 
message of length four (including one more byte for the 
entry size). In the case shown, the programmer has simply 
chosen to suspend the task if this situation arises. 

The function getq( ) is declared similarly: 

getq(source, dest) 

It also returns a - 1 if no entry is present in the queue 
pointed to by argument “source.” 

Using these two primitive functions to perform the 
actual queue access operations, one can write other useful 
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Re-entrancy 

The term re-entrancy usually describes a phenom¬ 
enon that occurs in shared code segments. However, a 
similar problem occurs in shared data segments. 

Code re-entrancy. Consider a situation in which an in¬ 
terrupt handler is part-way through its processing 
operations when the same interrupt happens again. If 
the handler re-enables interrupts (after saving the inter¬ 
rupted program’s context) then the second interrupt 
will be serviced. That is, the context of the first interrupt 
process will be saved and the interrupt handler will be 
re-entered. The handler will proceed to process the sec¬ 
ond interrupt’s data, perhaps by queueing some input 
data in an output queue and waking a task. It will then 
restore the context of the interrupted program and 
return control to it. In this case the interrupted program 
is the interrupt handler itself! At this point, two prob¬ 
lems may arise. First, rf the handler is programmed to 
store data in fixed memory locations, the data com¬ 
puted when the handler was called the first time have 
been overwritten by the computations performed by 
the second call. Second, even if the first problem is 
solved, the data received by the second interrupt will 
get queued before the data for the first. The received 
data will therefore be out of time sequence. The second 
problem must be solved either by keeping interrupts 
disabled within the handler or by ensuring that the 
handler’s execution time is less than the minimum time 
between interrupts. 

The first problem illustrates the code re-entrancy 
phenomenon. It will occur whenever a shared segment 
of code is called by a number of asynchronously run¬ 
ning programs (or by an interrupting device, as de¬ 
scribed). For example, the queue-access functions, de¬ 
scribed in the main article, experience the same 
phenomenon. The problem is solved by ensuring that a 
separate data segment is reserved each time the 
shared code segment is entered. 

Some modern compilers accomplish re-entrancy 
automatically by reserving a space (frame) on the stack 
for parameters passed in a function call and for certain 
data types defined by the language. A “frame pointer” 
is used to locate the data on the stack, and a new frame 
is allocated for each call to the function. Therefore, to 
write a re-entrant code segment, the programmer must 
simply use data types for which space will be allocated 
on the stack by the compiler. In the C language this is 
accomplished by defining dynamic (i.e., non-static) 
variables within the body of a function. The compiler 
will allocate space for them in a stack frame. 

Another way to solve the code re-entrancy problem is 
to have each calling program pass a pointer to a re¬ 
served data area as part of the shared segment call pro¬ 
cedure. The shared code segment would then use the 
pointer to locate storage for all internal parameters. 

The important point is that each time the shared 
code segment is called, a separate storage area must 
be allocated for all variables manipulated by the seg¬ 
ment. 


Data re-entrancy. Suppose that a system is designed 
in which data are passed between an interrupt handler 
and a task by means of a simple buffer, rather than a 
queue. Suppose further that in a certain instance the 
task is part-way through processing the data when a 
second interrupt is received from the same source. The 
interrupt handler will overwrite the buffer with new data 
and then allow the task to continue. At this point the 
task will be working with inconsistent data and the 
results will be incorrect. 

The problem could be described as one of “data re- 
entrancy.” That is, new data were entered into the buf¬ 
fer before the previous data had been completely pro¬ 
cessed. The same problem can occur for data passed 
between tasks if the tasks are scheduled preemptively 
or, in a nonpreemptive system, if the programmer is not 
careful to complete the processing of a buffer’s data 
before suspending a task. 

Note that the use of queues to pass data between 
asynchronously running program components elimi¬ 
nates the problem. However, if the messages passed 
are very large, the overhead required by the queue 
mechanism may be too great and the shared buffer 
technique may be warranted. In such situations, if cer¬ 
tain precautions are observed, the data re-entrancy 
problem may be avoided. 

The problem may be solved by defining a flag called a 
“gate” (also called a semaphore) for each data buffer. 
The gate controls access to the shared buffer. If a func¬ 
tion wishes to access the buffer it first checks the gate 
to see if it is open (reset, zero). If it is, it closes it (sets it) 
and proceeds to manipulate the buffer’s data. When it 
is finished it re-opens the gate so that other functions 
may access the buffer. The “open” operation may, in 
fact, wake a task that is waiting for buffer access in a 
manner similar to that used by the queue access func¬ 
tions getqwt() and putqwt(), as described in the main 
article. 

The only problem in using this technique is that the 
process of testing the gate and setting it must not be in¬ 
terrupted, since the interrupting program could also 
test the gate, find it open, and close it. Then two func¬ 
tions would be accessing the buffer simultaneously. To 
avoid this problem the “test and set” operation must be 
performed in a single machine instruction. Unfor¬ 
tunately, the Z80 microprocessor does not have this in¬ 
struction. However, it could be simulated by disabling 
interrupts while the operation is performed. 

A compromise approach might be to use a queue to 
pass a buffer pointer. Multiple buffers could then be 
used. If the number of queue entries matches the 
number of buffers, then the use of putqwt() and 
getqwt() to pass the pointers would eliminate the over¬ 
write problem if the program is written SD that the 
pointer must be successfully queued before the cor¬ 
responding buffer is overwritten. 
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functions that have general application within a task¬ 
scheduling environment and support the orderly flow of 
messages between tasks. For example, a function may be 
designed so that when an attempt is made to enter a 
message into a full queue, the task will be suspended. 
Later, when a message is removed, the suspended task will 
be awakened so that it can store its message. The sus¬ 
pended task identifies itself by storing its task number in 
the queue’s header in item “task.” Such a function might 
be declared as follows: 

putqwtfsource, dest, stask, count) 

The function name suggests that the task will put a mes¬ 
sage in the queue if room exists but will wait [suspend, call 
sleep( )] if not enough room exists. Parameter “stask” 
specifies the number of the calling task. * Similarly, a func¬ 
tion to remove messages from a queue, getqwt( ), may be 
designed so that when a task attempts to remove a message 
from an empty queue it will be suspended. When a mes¬ 
sage is later placed in the queue the suspended task will be 
awakened. 

Since only one location in a queue’s header is allocated 
for storing the number of a waiting task, a queue can have 
only one source task using the putqwt() function and one 
destination task using the getqwtf) function. A more 
elaborate scheme could be devised in which a queue of 
waiting tasks could be maintained. However, the im¬ 
plementation of separate queues for each data path avoids 
the problem and simplifies the design. 

By using putqwtf) and getqwt( ) it is possible to control 
the execution of tasks in response to the availability of 
messages to process in their input queues and the avail¬ 
ability of space to store messages in their output queues. 
For example, if an output device becomes momentarily 
blocked, the queues that feed it messages will become 
“backed up,” thereby suspending the corresponding 
tasks. When the device becomes unblocked, the tasks 
waiting to send data will be awakened in an orderly man¬ 
ner, based upon the availability of storage space in their 
respective output queues. The flow of messages is similar 
to the flow of automobiles in a traffic tie-up on a major 
highway. 


System operation 

After the initialization of each task, as described earlier, 
main() calls wake() to schedule the initialization task, 
init( ), and sets the TCB linked-list pointer to init( )’s TCB 
so that the scheduler will test init( )’s TCB first [init() is 
the highest priority task]. Function main() then calls 
sched( ) and, from this point on, control is never passed 
back to main() unless the system is reset from hardware. 
The sched() function then checks init( )’s TCB and passes 
control to it. 

Task init( ) performs the initialization operations re¬ 
quired first during startup and later during restart. That is, 

•Note that the number of the task currently running is the index of its TCB 
in the TCB linked list structure. Since this is known to the scheduler, it need 
not be specified as an argument. This would eliminate a possible source of 
programming error. 


init() is programmed so that if another task or interrupt 
handler wakes it, it will restart the application program 
from the beginning. It performs these operations with in¬ 
terrupts disabled, and it enables interrupts just before it 
suspends itself. 

The first operation performed in init() is to link all the 
TCB’s together in a loop. This is accomplished by setting 
the forward-link pointers in the TCBs. As described 
earlier, the last (lowest priority) TCB is linked to the first 
so that the scheduler will loop looking for READY tasks. 
The init( ) function then performs other application- 
specific restart initialization operations and finally 
suspends itself by calling sleep(). These operations may 
involve waking application tasks. However, if other tasks 
are not awakened, the scheduler will simply loop until an 
interrupt handler wakes a task. 

Tasks and interrupt handlers provide the various data 
processing and control services required by the particular 
application. For example, most real-time applications will 
be required to service interrupts from a hardware timer 
device. The interrupt handler wakes a timer task which, in 
turn, provides interval timing services to other application 
tasks. Applications that provide a man-machine interface 
will usually need to service a keyboard. The interrupt han¬ 
dler for this device places the received keystroke character 
in an output queue and wakes a keyboard task. This task 
will then input the character from the queue and process it. 
Tasks and interupt handlers may also be defined to process 
data from other sources such as communication channels 
or measurement sensors. 

Tasks processing data inputs will usually wake tasks that 
provide data to output devices. These might be video or 
alphanumeric displays, communication channels, or 
equipment controllers. The typical output device is de¬ 
signed to receive a byte of data and then produce an inter¬ 
rupt when it is ready to receive the next byte. The interrupt 
handler must therefore be designed to output subsequent 
bytes until the entire message has been sent. It then wakes 
the output task. The output task must- initiate the transfer 
by sending the first byte and then suspend itself and wait to 
be awakened by the interrupt handler. It may be assured 
that the wakeup was from the interrupt handler if the 
handler sends a “signal” byte message to the task before 
waking it. The task, on being awakened, checks the queue 
from the interrupt handler and possibly other input queues 
to determine the source of the wakeup. 


T o date, the executive has been used in six projects. 

Applications have ranged from a data acquisition unit 
to a rather complex multiprocessor control/display unit 
incorporating keypad, color graphics, and audio annun¬ 
ciation devices. The project teams have experienced 
substantial improvements in software development and 
subsequent maintenance costs. In spite of diverse system 
requirements on these projects, the executive has 
undergone few changes since its initial shakeout period. 
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Since the executive’s design has been kept simple and 
has been implemented in a high-level language, it may be 
understood both by those assigned to write the initial ap¬ 
plication programs and those assigned to maintain the 
system. Thus is not beyond the means of a small program¬ 
ming team to construct a software environment within 
which real-time application programs may be produced at 
reasonable cost. ■ 
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Appendix: Implementation 

The executive was originally implemented using a C 
cross compiler that runs on a minicomputer and produces 
optimized Z80 code. 1 This provides an excellent environ¬ 
ment for producing major real-time systems. However, 
for more modest systems and to aid the reader interested in 
the subject of real-time programming, a version has been 
prepared that uses the less expensive C/80 C compiler 2 
This is a “native” compiler, meaning that it runs on the 
target machine. It produces 8080 microprocessor code that 
will run on the Z80 machine. 

The C/80 version, called CX/80, includes source files 
for the task scheduler, a set of queue assess functions, ex¬ 
ample application tasks and interrupt handlers, and two 
runable demonstration programs. It can be supplied in 
most 5!4” single sided disk formats. Those interested 
should contact INTR-SOFT Co., Box 351, Bedford, MA 
01730. 


1. Z80 C Cross-compiler, Vandata, 17554 Midvale Ave N. Suite 205, Seat¬ 
tle, Wa 98133 (205) 542-7600. 

2. C/80 C Compiler, Version 2.0 or 3.0, The Software Toolworks, 15233 
Ventura Blvd. Suite 1118, Sherman Oaks, CA 91403 (213) 986-4885. 
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This proposed standard allows small increments of HO to be added or 
modified in an easy, cost-effective way. It is offered here for public 
comment before submission to the IEEE Standards Board. 


P959 I/O Expansion Bus 

Proposed Standard 


I/O Expansion Bus Subcommittee 
IEEE Computer Society Microprocessor Standards Committee 


D raft 3 of the proposed IEEE 959 I/O Expansion Bus 
Standard is the result of an effort by a working 
group of the IEEE Computer Society’s Microprocessor 
Standards Committee. The P959 bus provides for the con¬ 
version of a simple, cost-effective standard input/output 
bus into a special input/output interface. The final 
specification will standardize the interface for I/O expan¬ 
sion board products and provide for compatibility 
throughout the industry. The proposed specification 
defines the logical, electrical, and mechanical aspects of 
the P959 bus and P959 I/O expansion boards. 

The P959 bus offers a unique design approach to 
board-level users. To date, board-level designs based on 
industry standards have dictated that systems be based 
on single-board computers and I/O boards joined via 
system backplanes. These backplanes include memory ad¬ 
dress, control, and data paths. More recently, de facto 
industry-standard personal computers based on the IBM 
PC have used this approach to I/O expansion, with the 
PC bus providing expansion capability to the PC’s 
“motherboard.” The expansion boards specified by P959 
bring a new concept to I/O expansion—they provide for 
smaller modules that can be plugged directly onto single¬ 
board computers so that the I/O can be tailored to par¬ 
ticular applications with minimal cost and space. Expan¬ 
sion modules can convert the general-purpose P959 I/O 
Expansion Bus into a special-purpose I/O interface such 
as parallel I/O, serial I/O, RS-232C, and IEEE 488. 


The P959 bus signals are derived directly from the on¬ 
board address and control buses. The I/O transaction 
does not require the access arbitration or line buffering 
that is typical of system-bus I/O; hence, the interface re¬ 
quires less silicon, resulting in lower cost. The mechanical 
interface between the P959 expansion board and the P959 


What is P959? 

The P959 bus is a unique interface that facilitates 
on-board I/O expansion via small, specialized I/O ex¬ 
pansion boards which plug directly into base boards. 
The mechanical interface between a P959 expansion 
board and a P959 base board is a pin-and-socket 
connector. 

The P959 expansion board concept offers a flexible 
design approach to board-level users. To date, board- 
level designers have had to configure systems based 
on single-board computers and I/O boards joined via 
system backplane buses. P959 expansion boards bring 
a new concept to I/O expansion—they provide a fami¬ 
ly of small modules that can be plugged directly onto 
single-board computers. With P959 expansion 
modules, users can tailor their applications directly 
on single-board computers at minimal cost. 
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base board is a unique pin-and-socket bus connector com¬ 
plemented by nonconducting threaded mounting spacers. 
Consequently, an expansion board plugged into the P959 
bus becomes an integral part of the single-board 
computer. 

The P959 committee consists of IEEE members who 
are employees of single-board computer manufacturers 
and connector manufacturers as well as of members who 
are system integrators and end users. Some of the more 
active members were Leon Adams (chairman) of Texas 
Instruments, Pete MacWilliams of Intel, Warren Buster 
of Viking Connector, Richard Main of Signetics, Peter 
Hoa of National Semiconductor, and Juan Monico of 
AMD. All were interested in providing flexible, low-cost, 
single-board computer I/O that would be plug-compatible 
and interchangeable between different companies’ prod¬ 
ucts. Other interested parties, though they were not ac¬ 
tive committee members, were kept abreast of the com¬ 
mittee’s activities via mailings of drafts and were en¬ 
couraged to comment. 

The proposed P959 standard started with the iSBX bus, 
which is currently supported by a number of single-board 
computer manufacturers. The proposal was put through 


the wringer for system design, timing, and nomenclature 
to ensure clarity and compatibility with industry stan¬ 
dards. The following is a condensed version of the 
resulting P959 specification. Portions of Section 
4—Mechanical Specification, all of Section 5—Connector 
Specifications, and Appendices A and B have been omit¬ 
ted from this printing to save space. A copy of the entire 
P959 specification is available from 

Leon Adams, P959 Chairman 
Texas Instruments Incorporated 
PO Box 1443, M/S 6944 
Houston, TX 77001 

Readers are encouraged to forward any comments regard¬ 
ing P959—either technical or nontechnical—to Leon 
Adams at the above address. The committee will discuss 
such comments and prepare a reply. 

The proposed standard 

Draft 3, April 11, 1983 

Table of contents 
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3.3 Driver and receiver specifications 

4. Mechanical specifications 

4.1 Connector pin assignments 

4.2 Expansion module specifications 
4.3* Baseboard specifications 

4.4* Board height specifications 
4.5* Mounting techniques 

5. * Connector specifications 

5.1* Reference documents 
5.2* Mechanical requirements 
5.3* Electrical requirements 
5.4* Environmental requirements 

6. Levels of compliance 

6.1 Variable elements of capability 

6.2 Baseboards and expansion modules 

6.3 Compliance level notation 


List of appendices 

Appendix A* Printed-circuit hole size and 
contact size 

Appendix B* I/O connector examples 


*To save space, we have omitted Sections 4.3 to 4.5, Sections 
5.0 to 5.4, and Appendices A and B. These sections will pri¬ 
marily be of interest to manufacturers—copies of them can be 
obtained from the working group chairman, Leon Adams, at 
Texas Instruments Inc., PO Box 1443, M/S 6944, Houston, TX 
77001. 


1. General 

1.1 Scope 

One of the most important parts of any computer sys¬ 
tem is the I/O. Many systems require different types of 
I/O depending on the specific application. In addition, 
the system designer is faced with a significant challenge 
to keep up with new technology in I/O device types, 
interfaces, and the LSI components designed to support 
them. The P959 I/O Expansion Bus is designed to address 
these needs. Using this standard interface allows small 
increments of I/O to be added or modified in an easy, cost- 
effective way. 

The P959 I/O Expansion Bus is specified independent 
of processor or board type. Each expansion interface sup¬ 
ports up to sixteen 8-bit I/O ports directly. Enhanced 
addressing capability is available using slave processors 
or FIFO devices. In addition, each expansion interface 
may optionally support a DMA channel capable of data 
rates up to 2M words/sec. These features are supported 
for both 8- and 16-bit data paths. 

This specification has been prepared for those users 
who intend to design or evaluate products that will be 
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compatible with the P959 I/O Expansion Bus. For this 
purpose, functional, electrical, and mechanical specifi¬ 
cation are covered in detail. The intent of the specification 
is to guarantee compatibility between baseboards and 
expansion modules while not restricting the actual designs 
any more than necessary. Additional design considera¬ 
tions that are not part of the actual specification are pre¬ 
sented in the appendices.* 

1.2 Definitions 

The following paragraphs contain definitions that are 
used throughout this specification. More detailed defini¬ 
tions can be found in the appropriate section of this 
specification. 

1.2.1 General system term definitions 

Compatibility. The degree to which devices may be 
interconnected and used without modification, when 
designed as defined in Sections 2,3, and 4 of this speci¬ 
fication. Section 6 discusses the various levels of compli¬ 
ance that the specification allows. 

Operation. The process whereby digital signals effect 
the transfer of data across the interface by means of a 
sequence of control signals. Operations may be either 
interlocked or full speed. 

Interface. A shared boundary between two systems or 
parts of systems through which information is transferred. 

System. A set of interconnected elements which 
achieve a given objective through performing a specific 
function. 

Arbitration. The process of determining which request¬ 
ing device will gain access to a resource. 

1.2.2 Signals and paths 

Bus. A signal line or set of signal lines used by an 
interface system to connect a number of devices and to 
transfer data. 

Byte. A group of eight adjacent bits of data that are 
operated on as a unit. 

Word. Two bytes operated on as a unit. 


*The appendices are not included with this printing of the draft. 
See footnote following Table of Contents. 
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Data path. Signal lines on a bus associated with data. 

High state. The more positive voltage level; used to 
represent one of two logical binary states (see Section 

3.1.1 for more details). 

Low state. The more negative voltage level; used to 
represent one of two logical binary states (see Section 

3.1.1 for more details). 

Signal. The physical representation of a logical value. 

Signal level. The relative magnitude of a signal when 
compared to a reference. Signal levels in this specification 
are specified in volts. 

Signal line. One of a set of signal conductors in an 
interface system used to transfer messages among inter¬ 
connected devices. 

Active-high signal. A signal for which the logical-true 
(activated) state is represented by the high electrical state, 
and the logical-false (deactivated) state is represented by 
the low electrical state, in this specification, the active- 
high signal can be identified by the absence of an asterisk 
(*) at the end of the signal name (refer to Section 3.1.1 
for more details). 

Active-low signal. A signal for which the logical-false 
(deactivated) state is represented by the high electrical 
state, and the logical-true (activated) state is represented 
by the low electrical state. In this specification, the active- 
low signal can be identified by the presence of an asterisk 
(*) at the end of the signal name (refer to section 3.1.1 
for more details). 

Two-directional signal line. A signal line that may be 
defined in either direction across an interface, and that 
cannot be defined in both directions simultaneously. The 
direction of operation for a two-directional signal line in 
a system is a configuration option. 

Bidirectional signal line. A signal line that may be 
defined in either direction across an interface. The direc¬ 
tion is determined by control signals for each operation. 

2. Functional description 

The P959 I/O Expansion Bus concept allows low-cost, 
highly flexible I/O expansion for computer boards. This 
section provides an overall understanding of the concept 
by describing the elements of the bus system, the bus 
interface signals, and the bus operations. 


There are two basic elements in the P959 I/O Expansion 
Bus; the baseboard and the expansion module. 

2.1.1 Baseboard 

A baseboard is any board which provides one or more 
I/O expansion interfaces (connectors) that meet the elec¬ 
trical and mechanical requirements of this specification. 
Logically, the baseboard is always the master device, 
making it responsible for generating all addresses, chip 
selects, and commands. As a master device for DMA 
transfers, the baseboard is required to provide the DMA 
controller function. Mechanically, the baseboard shall 
supply the latching connector(s) and mounting hole(s) for 
attaching the expansion module with nylon screws and 
spacers. See Figures 1 and 2 for mounting details. 

2.1.2 Expansion Module 

An expansion module is a small, specialized I/O board 
which attaches to a baseboard. Each expansion module 
can be one of two standard sizes, single wide or double 
wide; each is shown in Figures 1 and 2, respectively. The 
purpose of an expansion module is to convert the general 
bus interface into a specific I/O interface. An example of 
this would be an RS-232 serial interface module. The 
P959 I/O Expansion Bus is specifically designed to sim¬ 
plify the expansion module interface. In many cases, LSI 
peripheral components can connect to this interface 
directly. 

2.2 Bus Signals 

The P959 I/O Expansion Bus signals can be grouped 
into seven classes based on the functions they perform. 
The classes are 

(1) address and chip select lines, 

(2) data lines, 

(3) control lines, 

(4) interrupt lines, 

(5) option lines, 

(6) power lines, and 

(7) reserved lines. 

2.2.1 Address and Chip Select Lines 

These lines can be broken into two groups: 

Function Signals 

Address MAO, MA1,MA2 

Chip select MCSO*, MCS1 * 

The function of these signals is somewhat unique. A 
typical bus would simply have address lines and require 
the slave device to create its own chip selects. The P959 
I/O Expansion Bus requires the baseboard to generate 
chip selects. This feature simplifies the expansion mod¬ 
ules with only minimal impact to the baseboard. 

2.2.1.1 Address lines (MAO, MAI , MA2) 

The address lines are active-high signals generated by 
the baseboard from the low-order address lines. MAO is 
the least significant address bit. For an 8-bit baseboard, 
these lines connect directly to the least significant address 
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bits AO, A1, and A2. For a 16-bit baseboard, the address 
line connections are: MAO to A1, MAI to A2, and MA2 
to A3 (AO is used along with byte high enable to control 
byte/word transfers). During DMA operations, the state 
of the address lines is undefined. 

2.2.1.2 Chip selects (MCSO*, MCS1*) 

The chip selects are active-low signals generated by the 
baseboard to enable communication with the expansion 
module. These lines may transition when they are not 
required to be valid. It is the responsibility of the expan¬ 
sion module to qualify the chip-select signals with com¬ 
mands (note that this is done internally in many LSI 
components). Chip selects shall remain high during a 
DMA operation. 

The chip-select lines are defined differently for 8- and 
16-bit baseboards as shown in Figure 3. For 8-bit base¬ 
boards, each chip select enables eight consecutive ports 
as specified by the three address lines. For 16-bit boards, 
there are two cases: an 8-bit expansion module and a 16- 
bit expansion module. 

For a 16-bit baseboard driving an 8-bit expansion mod¬ 
ule, the chip-select operation is similar to the 8-bit base¬ 
board. The 8-bit expansion module connects to the low 
byte on the data bus which makes it only accessible 
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through even ports (odd-ports transfer over the high byte). 
Each chip select therefore enables eight consecutive even 
ports as determined by the three address lines (note that 
this mode also allows each chip select signal to enable 
eight consecutive 16-bit ports for 16-bit expansion 
modules). 

The chip selects on a 16-bit baseboard with a 16-bit 
expansion module have two functions. In addition to en- 



Figure 1. P959 I/O Expansion Bus system with single-wide expansion module. 
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abling communication, they control high-byte, low-byte, 
and word transfer modes. MCSO* is used to enable a low- 
byte transfer (even ports), MCS1* is used to enable a 
high-byte transfer (odd ports) and both are used for a word 
transfer. The three address lines determine which of eight 
16-bit ports are being addressed. 


2.2.2 Data lines (MD0-MD15) 

The data lines are used to transmit or receive data to or 
from the expansion module ports. The 16 active-high, 
bidirectional lines are organized in two groups (bytes) of 
eight lines each. The low byte (MD0-MD7) is used for 
all transfers on 8-bit baseboards and for all even-byte 
transfers on 16-bit baseboards. MDO is the least sig¬ 
nificant bit of this byte. The high byte (MD8-MD15) 
is used for all odd-byte transfers on 16-bit baseboards. 
MD8 is the least significant bit of this byte. Table 1 
presents a summary of the data bus functions for different 
configurations. 

2.2.3 Control lines 

The following signals are classified as control lines: 


Class Function Signal 

Commands I/O read IORD* 

I/O write IOWRT* 

Direct memory DMA request MDRQT 

access (DMA) DMA acknowledge MDACK* 

Terminate DMA TDMA 



Figure 2. P959 I/O Expansion Bus system with double-wide expansion module. 
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Initialize Reset RESET 

Clock Expansion module MCLK 

clock 

System control Expansion module wait MWAIT* 
Expansion module MPST* 

present 

2.2.3.1 Command lines (IORD*. JOWRT*) 

The command lines are active-low signals generated 
by the baseboard. An active command line indicates to 
the expansion board that the address and chip-select lines 
are valid and that the selected expansion module (i.e., 
one with active chip select) should perform the specified 
operation. The I/O read command (IORD*) is used by the 
baseboard to request data to be transferred from the expan¬ 
sion module. The I/O write command (IOWRT*) is used 
by the baseboard to transfer data to the expansion module. 

2.2.3.2 Direct memory access (DMA) lines 

The DMA lines control the communication link 
between a DMA controller on the baseboard and the 
expansion module. The use of these lines is optional on 
both the baseboard and the expansion module. 
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2.2.3.2.1 DMA request (MDRQT) 

This active-high signal from the expansion module to 
the baseboard DMA controller requests that a DMA cycle 
be initiated. Upon receipt of this signal the DMA con¬ 
troller begins arbitration for the baseboard’s local bus. 


Data Bus Not Connected 
for 8-bit Expansion Module 
at These Addresses 


Base 

Address 



8-bit Baseboard With 16-bit Baseboard With 16-bit Baseboard With 

8-bit Expansion Module 8-bit Expansion Module 16-bit Expansion Module 


Figure 3. Chip-select address ranges. 
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2.2.3.2.2 DMA acknowledge (MDACK*) 

This active-low signal from the baseboard to the expan¬ 
sion module indicates that a DMA operation has been 
granted (DMA controller has the bus). Like a chip select, 
this signal may transition when not valid and therefore 
shall be qualified by commands on the expansion module. 

2.2.3.2.3 Terminate DMA (TDMA) 

This is an active-high, two-directional DMA control 
signal. The specific direction shall be determined by con¬ 
figuration (i.e., jumper or tristate driver). Once confi¬ 
gured, TDMA may only operate in one direction. When 
generated by the expansion module, TDMA is used to 
terminate the DMA transfer. When generated by the base¬ 
board, TDMA is used to signal the end of a DMA transfer 
to the expansion module. Baseboards that support DMA 
shall be configurable to support TDMA in either direc¬ 
tion. An expansion module may support or not support 
TDMA, as required. 

2.2.3.3 Initialize (RESET) 

This active-high signal is generated by the baseboard 
to put the expansion module into a known state. The 
baseboard shall generate a power up reset when power is 
applied. During normal operation after a power up reset 
sequence, the expansion module may be reinitialized with 


a standard reset signal (refer to Section 3.2 for more 
details). 

2.2.3.4 Expansion module clock (MCLK) 

This input to the expansion module is a general purpose 
timing signal. The 9-10 MHz clock is asynchronous to all 
other bus signals. 

2.2.3.5 System control 

There are two system control signals (MWAIT* and 
MPST*) that are defined in the following paragraphs. 

2.2.3.5.1 Expansion module wait (MWAIT*) 

This active-low signal is generated by the expansion 
module to extend the current data transfer operation. 
While MWAIT* is activated, the baseboard is forced to 
insert wait states into the current bus cycle, allowing the 
expansion module more time to complete the requested 
operation. The MWAIT* signal is generated or enabled 
by a combination of valid chip select(s) and addresses or 
by a valid DMA acknowledge signal. As these lines 
change, MWAIT* may transition; however, it shall be 
stable no later than 75 nsec after MCSO*, MCS1*, and 
MDACK* become stable. 

Recognition of the MWAIT* signal by the baseboard 
is optional; however, it is strongly recommended. Only in 
cases where the processor does not support the signal 
should it be omitted, as it will limit the number of modules 
that are compatible with the baseboard. Baseboards that 
do not support the use of the MWAIT* signal may perform 
only the full-speed operations, as defined in Sections 

2.3.1 and 2.3.2. When it supports the MWAIT* signal, 
the baseboard shall guarantee (usually via a pull-up resis¬ 
tor) that the signal is inactive if not connected. Expansion 
modules shall support the MWAIT* signal if they cannot 
meet the full-speed operation specifications. 

2.2.3.5.2 Expansion module present (MPST*) 

This active-low signal is driven by the expansion mod¬ 
ule to inform the baseboard that a module is installed. 
Typically, this signal is connected to ground on the expan¬ 
sion module and to decode logic on the baseboard. When 
the signal is not activated, the I/O address space normally 
reserved for the expansion module may be used else- 


Table 1. 

Data bus function for different configurations. 


Configuration 


Lines Used 



MD0-MD7 

MD8-MD1 5 

8-bit baseboard 

16-bit baseboard with: 


X 

— 

8-bit expansion module 


X 

— 

16-bit expansion module — 

even byte 

X 

— 

16-bit expansion module — 

odd byte 

— 

X 

16-bit expansion module — 

word 

X 

X 
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where. One application of the MPST* signal is to allow 
an old product that did not include facilities for the P959 
I/O expansion to be upgraded with a new baseboard that 
includes P959 I/O expansion capability. Without expan¬ 
sion modules, the I/O addressing for the new baseboard 
looks the same as that of the old one. If the new baseboard 
requires expansion modules, they can be added and their 
presence recognized by an active MPST* signal. 

2.2.4 Interrupt lines (MINTRO, MINTR1) 

These active-high lines from the expansion module 
make interrupt requests to the baseboard. An interrupt 
line driven from the expansion module shall remain active 
until the baseboard services it. These lines are asynchro¬ 
nous to all other bus signals. 

2.2.5 Option lines (OPTO. OPT1) 

These lines are user-defined. Their purpose is to pro¬ 
vide connections for any unique system requirements. 
Examples would be additional interrupt lines or another 
DMA channel. Baseboards shall connect these lines to 
wire-wrap posts for configurability. 

2.2.6 Power lines 

All baseboards shall be capable of supplying + 5 Vdc 
and ± 12 Vdc. 

2.2.7 Reserved lines 

These two lines are reserved for future enhancements 
made possible through new technology. Baseboards 
and the expansion modules shall leave these lines 
unconnected. 

2.3 Bus operations 

The P959 I/O Expansion Bus supports I/O read, I/O 
write, DMA, and interrupt operations. 

2.3.1 HO read operations 

There are two types of I/O read operations on the P959 
I/O Expansion Bus; the full-speed I/O read and the inter¬ 
locked I/O read. Whether or not the expansion module 
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generates the MWAIT* signal determines which type of 
operation is performed. 

Figure 4 shows the full-speed I/O read operation. The 
baseboard generates a valid address and chip select for the 
expansion module to initiate the operation. After the set¬ 
up times are met, the baseboard activates the IORD* line 
for a minimum of 300 nsec. The expansion module shall 
generate valid data from the addressed I/O port within 250 
nsec after the IORD* line is activated. The baseboard 
then reads the data and deactivates the IORD* line. The 
baseboard is now free to change the address and chip- 
select lines for the next operation. 

Figure 5 shows the interlocked I/O read operation. The 
baseboard initiates the operation by generating a valid 
address and chip select, just as in the full-speed I/O read. 
The expansion module then activates the MWAIT* signal 
which in turn inhibits the ready signal to the baseboard 
processor. The baseboard will then activate the IORD* 
line and insert wait states as long as the MWAIT* signal 
from the expansion module is active. The expansion mod¬ 
ule will remove the MWAIT* signal when data is valid 
on the bus. The baseboard then reads the data and deac¬ 
tivates the IORD* line. The baseboard is now free to 
change the address and chip-select lines for the next oper- 



Figure 4. Full-speed I/O read operation. 
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ation. The interlocked I/O read operation shall be used by 
all expansion modules that require a read pulse width 
greater than 300 nsec or that cannot guarantee valid data 
on the data bus within 250 nsec after the IORD* line is 
activated. 

2.3.2 HO write operations 

There are two types of I/O write operations on the P959 
I/O Expansion Bus: the full-speed I/O write and the inter¬ 
locked I/O write. Whether or not the expansion module 
generates the MWAIT* signal determines which type of 
operation is performed. 

Figure 6 shows the full-speed I/O write operation. The 
baseboard generates a valid address and chip select to 
initiate the operation. After the set-up times are met, the 
baseboard activates the IOWRT* line and enables data. 
The IOWRT* line will remain active for at least 300 nsec 
and the data will be valid for at least 250 nsec before the 
IOWRT* line is deactivated. After the IOWRT* line is 
deactivated, the baseboard is free to change the address 
and chip-select lines for the next operation. 

Figure 7 shows the interlocked I/O write operation. The 
baseboard initiates the operation by generating a valid 


address and chip select, just as in the full-speed I/O write. 
The expansion module then activates the MWAIT* signal, 
which in turn inhibits the ready signal to the baseboard 
processor. The baseboard will then activate the IOWRT* 
line, enable data, and insert wait states as long as the 
MWAIT* signal is active. The expansion module will 
remove MWAIT* when it is ready to receive the data. 
The baseboard then deactivates the IOWRT* line and 
removes the data. Data shall be stable at least 250 nsec 
before the IOWRT* signal is deactivated. The baseboard 
is now free to change the address and chip-select lines for 
the next operation. The interlocked I/O write operation 
shall be used by all expansion modules that cannot guar¬ 
antee proper operation with a 300 nsec write pulse width. 

2.3.3 Direct memory access (DMA) operations 

DMA is a means of moving a block of data to or from 
an expansion module without the overhead of an interrupt 
service or processor polling routine. The source or des¬ 
tination of the data on the baseboard is typically a series 
of consecutive memory locations. For the expansion mod¬ 
ule, the source or destination is always an I/O port. The 
DMA process is always initiated by executing software 
on the baseboard that sets up the DMA controller and 
expansion module. This software determines the direction 
of data movement, the addresses of the source and desti¬ 
nation, and the length of the transfer. Once set up, DMA 
operations will be done automatically by the DMA con¬ 
troller, as requested by the expansion module. 

DMA operations are similar to I/O read and I/O write 
operations. Expansion modules that meet the require¬ 
ments for full-speed I/O read and I/O write operations can 
perform full-speed DMA operations. Likewise, expan¬ 
sion modules that meet the requirements for interlocked 
I/O read and I/O write operations can perform interlocked 
DMA operations. Once the DMA controller is set up, a 
DMA operation is initiated by the expansion module acti¬ 
vating MDRQT. The DMA controller then acquires (arbi¬ 
trates) the local bus on the baseboard and activates the 



Figure 5. Interlocked I/O read operation. 
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MDACK* line to the expansion module to acknowledge 
the request. The MDACK* line functions as a chip select 
for DMA operations. During a DMA operation, both chip 
selects (MCSO*, MCS1 *) are deactivated and the address 
lines (MA0-MA2) are undefined. The rest of the opera¬ 
tion is the same as the I/O read and I/O write operations 
described in sections 2.3.1 and 2.3.2, respectively. Fig¬ 
ures 8 and 9 show full-speed and interlocked DMA oper¬ 
ations, respectively. 

DMA operations can be done in two modes: cycle steal 
and burst. In the cycle steal mode, the expansion module 
will deactivate the MDRQT line every operation after 
receiving a command. The DMA controller, in turn, 
releases the bus after completing the operation. In the 
burst mode, the expansion module will hold the MDRQT 
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Figure 6. Full-speed I/O write operation. 



Figure 7. Interlocked I/O write operation. 
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line active until the last operation of a transfer. The burst 
mode will always attain equal or greater throughput, since 
the DMA controller only arbitrates for the bus once per 
transfer rather than once per operation. 

The TDMA line is provided for additional DMA con¬ 
trol. This line is configurable either as an output from the 
baseboard or as an input to the baseboard. 

As an output, the TDMA line identifies the end of a 
DMA transfer. In this mode, the baseboard activates the 
TDMA line after the last valid DMA operation is com¬ 
pleted. If the expansion module is holding MDRQT active 
when it receives an active TDMA line, it shall remove the 
MDRQT line as if it were a command. However, the 
baseboard need not wait for the MDRQT line to go active 
before activating the TDMA line. 



Figure 8. Full-speed DMA operation. 



Figure 9. Interlocked DMA operation. 
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As an input, the TDMA line shall terminate a DMA 
transfer on the baseboard. To accomplish this, the expan¬ 
sion module first deactivates the MDRQT line, and then 
activates the TDMA line. 

2.3.4 Interrupt operations 

The expansion module initiates an interrupt operation 
by activating one of the interrupt request lines (MINTRO, 
MINTR1). This signal will interrupt the baseboard pro¬ 
cessor, causing it to execute an interrupt service routine. 
The interrupt service routine performs two functions. 
First, it services the interrupt. This will typically consist 
of reading data from or writing data to the expansion 
module. Secondly, the service routine deactivates the 
interrupt line from the expansion module. In summary, 
from the expansion module’s point of view, the expansion 
module initiates an interrupt by activating its interrupt 
signal line and deactivates the interrupt signal line when 
the baseboard tells it to do'so. 


3. Electrical specifications 

The electrical considerations required for the bus 
include the following: logical and electrical state rela¬ 
tionships, environmental considerations, power supply 
specifications, signal line characteristics, timing specifi¬ 
cations, and driver/receiver specifications. 
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3.1 General bus considerations 

3.1.1 Logical and electrical state relationships 

The signal name indicates whether the signal is active- 
high or active-low. If a signal name ends with an asterisk 
(*). then the signal is active-low and has the logical- 
electrical state relationship as listed in Table 2. 

If the signal name does not end with an asterisk, then 
the signal is active-high and has the logical-electrical state 
relationship as listed in Table 3. 


Table 2. 

Active-low signal characteristics. 


Logical State 

Electrical State 

Signal Level 

At Receiver 

At Driver 

0 (deactivated) 

H = TTL High State 

5.25V3=H=22.0 V 

5.25V=sH3s2.4V 

1 (activated) 

L = TTL Low State 

0.8V2=L=5-0.5V 

0.5V5=L3s0V 


Table 3. 

Active-high signal characteristics. 


Logical State 

Electrical State 

Signal Level 

At Receiver 

At Driver 

0 (deactivated) 

L = TTL Low State 

0.8V3=L2i —0.5V 

0.5V2=L3=0V 

1 (activated) 

H = TTL High State 

5.25V=5H=22.0V 

5.25VS3HS52.4H 
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These specifications are based on TTL, where the 
power source is 5V ±5 percent, referenced to logic 
ground. 

3.1.2 Signal line characteristics 

The settling time for commands, interrupts, MDRQT, 
TDMA, and MCLK, after a transition, is zero. These 
control lines are used to determine the state of the bus. 
Ringing beyond the noise immunity levels for these signal 
lines could cause system failures. Address lines, chip- 
select lines, data lines, MDACK*, and MWAIT* can ring 
beyond the noise immunity levels as long as they remain 
stable for their specified set-up times. 

3.1.3 Power supply specifications 

Table 4 gives the power supply specifications for the 
P959 I/O Expansion Bus. The maximum current specifi¬ 
cation is for one expansion module connector. A base¬ 
board or system may optionally limit the total power to a 


group of connectors as long as these specifications are 
met for each individual expansion module connector. The 
voltage specifications at the connector are measured over 
the full current specification range. 

3.1.4 Environmental considerations 

The electrical specifications shall be met within the 
following environmental conditions. 

3.1.4.1 Operating conditions 

Bus specifications should be met with operating envi¬ 
ronmental conditions in the following ranges: 

Temperature: 0°C to 55°C (32°F to 131°F) with free- 
moving air; 

Humidity: 0 percent to 95 percent without 

condensation. 

3.1.4.2 Storage 

Bus specifications should be met with nonoperating 
environmental conditions in the following ranges: 

Temperature: — 40°C to 70°C ( —40°F to 158°F); 
Humidity: 0 percent to 95 percent without 

condensation. 

3.2 Timing specifications 

This section provides all timing specifications on the 
P959 I/O Expansion Bus. Table 5 summarizes the timing 
specifications shown in the timing diagrams (Figures 10 
through 16). All timing is measured at 0.8 Vdc for low 
and 2.0 Vdc for high over the full load impedance (resis¬ 
tance and capacitance). 

3.3 Driver and receiver specifications 

This section specifies all driver types and DC specifi¬ 
cations for the P959 I/O Expansion Bus. Table 6 sum¬ 
marizes the specifications. 


Table 4. 

Power requirements. 



Voltage 


Current 

Minimum 

Nominal 

Maximum 

Maximum 

Volts 

Volts 

Volts 

Amps 

+ 4.75 

+ 5.00 

+ 5.25 

3.0 

+ 11.4 

+ 12.0 

+ 12.6 

1.0 

-12.6 

-12.0 

-11.4 

1.0 

— 

GND 

— 

6.0 
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4. Mechanical specifications 

This section describes the physical and mechanical 
specifications that a designer must be concerned with 
when designing a baseboard or an expansion module com¬ 
patible with the P959 I/O Expansion Bus. Detailed spec¬ 
ifications for the connector are contained in Section 5.* 


*Section 5 is not included with this printing of the draft. See 
footnote following Table of Contents. 


Table 5. 

AC specifications. 


Symbol Parameter 

Min (ns) 

Max (ns) 

Figure 

Reference 

tl 

Address stable before read 

50 

_ 

10 

t2 

Address stable after read 

30 

_ 

10 

t3 

Read pulse width 

300 

_ 

10 

t42 

Data valid from read 

0 

250 

10 

t5 

Data float after read 

0 

150 

10 

t6 

Time between commands 

— 

Note 3 

_ 

t7 

Chip select stable before command 

25 

_ 

10,11 

t8 

Chip select stable after command 

30 

_ 

10,11 

t9 

Power up reset pulse width 

50 Msec 

— 

16 

tl 0 

Address stable before write 

50 

_ 

11 

til 

Address stable after write 

30 

_ 

11 

tl 2 

Write pulse width 

300 

_ 

11 

t13 2 

Data valid to write 

250 

_ 

11 

tl 4 

Data valid after write 

30 

_ 

11 

tl 5 

MCLK cycle 

100 

110 

15 

tl 6 

MCLK width 

35 

tis-35 

4 Msec 

15 

tl 7 1 

MWAIT* pulse width 

0 

10,11 

t18 5 

Reset pulse width 

50 usee 

_ 

16 

N9 1 

Chip select or MDACK* to MWAIT* valid 

0 

75 

10,11 

t20 

MDACK* set up to command 

25 

_ 

12 

t21 

MDACK* hold after command 

30 

_ 

12 

t22 4 

Command or TDMA to MDRQT removed 

— 

150 

12 

t23 

TDMA pulse width 

300 

_ 

13,14 

t24 1 

MWAIT* to valid read data 

_ 

0 

10 

125 ^ 

MWAIT* to write command 

0 

_ 

11 

t26 

MDRQT inactive to TDMA 

0 

— 

14 

Note 1 

Note 2 

Note 3 

Note 4 

Note 5 

Required only if MWAIT* is activated. 

If MWAIT* not activated. 

To be specified by each expansion module. 

Required in cycle steal mode and for last operation in burst mode. 

Use t9 for first reset after power up and tl 8 for any further reset. 
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4.1 Connector pin assignments 

There are two types of connector pairs used for the 
P959 I/O Expansion Bus; a 36-pin, 8-bit version and a 
44-pin, 16-bit version. The 36-pin male connector on the 
expansion module will mate with either the 36 pin (8-bit) 
or the 44-pin (16-bit) female connectors on the baseboard. 
The 16-bit, 44-pin male connector on the expansion mod¬ 
ule will mate with only the 44-pin (16-bit) female con¬ 
nector on the baseboard. The pin locations are shown in 
Figure 17. Table 7 lists the pin assignments. 

4.2 Expansion module specifications 

There are two standard outlines for expansion modules. 
The single-wide outline is shown in Figure 18. The dou¬ 
ble-wide outline is shown in Figure 19. For each outline, 
either edge-finger connectors or pin-and-socket connec¬ 
tors may be used. When edge-finger connectors are used, 


they shall conform to the additional specifications con¬ 
tained in Figure 20. For pin-and-socket connectors, there 
are no additional restrictions. Details of the I/O connector 
positioning are determined by the user with some exam¬ 
ples provided in Appendix B.* 


Sections 4.3-4.5 and Sections 5.0-5.4 are omitted to 
save space—see note following the Table of Contents. 


6. Levels of compliance 

This section presents the concept and notation of levels 
of compliance for the P959 I/O Expansion Bus. The 
notion of levels of compliance is included to allow the 
use of P959 I/O Expansion Bus products of varying capa¬ 
bilities manufactured by diverse vendors. It bounds the 
variability allowed within the P959 I/O Expansion Bus 
specification, and provides a succinct and convenient 
notation for these variables. 

6.1 Variable elements of capability 

The P959 I/O Expansion Bus allows for variation in the 
data path width, DMA support, and interlocked opera¬ 
tion. Each is discussed in the following paragraphs. 

6.1.1 Data path 

Data path variations exist for both expansion modules 
and baseboards. Expansion modules may either support 
8- or 16-bit data paths. 16-bit baseboards may support 
only 8-bit data paths or both 8- and 16-bit data paths. 8- 
bit baseboards may support only 8-bit data paths. 

♦Appendix B is not included with this printing of the draft. See 
footnote following Table of Contents. 
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6.1.2 DMA support 

Both expansion modules and baseboards may option¬ 
ally support DMA operations. In order for DMA to be 
used in a system, both the expansion module and base¬ 
board shall support the signals that are required (MDRQT, 
MDACK*, and TDMA). 

6.1.3 Interlocked operation 

Baseboards may optionally not support this feature. 
Expansion modules may optionally require this feature. 
The feature is implemented via the MWAIT* signal. Typ¬ 
ically, baseboards will support the interlocked operation 
and expansion modules will not require it. The purpose 
for not requiring interlocked operation from all base¬ 
boards is to allow the use of low-cost, single-chip micro¬ 
controller devices that do not support a ready function. 

6.2 Baseboards and expansion modules 

When constructing a P959 I/O Expansion Bus system, 
it is not necessary that all modules have identical capa¬ 
bilities. The only restriction is that the system will only 
support modes of operation supported by both the base¬ 
board and the expansion module. For example, an expan¬ 
sion module that supports DMA cannot be plugged onto 
a baseboard that does not support DMA and result in a 
system that supports DMA. It is the responsibility of the 
system designer to guarantee that a required system fea¬ 
ture is supported by all system components. 
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6.3 Compliance level notation 

The following notation allows a vendor to succinctly 
and accurately specify a product’s level of compliance 
with the P959 I/O Expansion Bus specification. The lack 
of an element specification implies that either (1) there is 
no compatibility or (2) there is no requirement for that 
element. 

6.3.1 Data path 

D8 represents an 8-bit expansion module. 


Table 6. 

DC specifications. 


Driver 


Receiver 


Signal 

Type 

*OL 

■oh 

Co 

■lL 


C, 

MA0-MA2 

TTL 




-0.5 

70 

40 

MCS0\ MCS1 * 

TTL 

— 

— 

— 

-4.0 

100 

40 

MDACK* 

TTL 

— 

— 

— 

-1.0 

100 

40 

MD0-MD1 5 

TR1 

1.6 

-300 

130 

-0.45 

70 

40 

IORD*, IOWRT* 

TTL 




-1.0 

100 

40 

MWAIT* 

TTL 

1.6 

-50 

40 

— 

— 

_ 

MDRQT 

TTL 

1.6 

-50 

40 

— 

— 

_ 

TDMA 

TTL 

1.6 

-50 

40 

-1.0 

100 

40 

RESET 

TTL 

— 

— 

— 

-2.1 

100 

40 

MCLK 

TTL 

— 

— 

— 

-2.4 

100 

40 

MINTRO, MINTR1 

TTL 

2.0 

-100 

40 

— 

— 

_ 

OPTO, OPT 1 1 

TTL 

2.0 

-100 

40 

-2.0 

100 

40 

MPST* 

TTL 

2.0 

-100 

40 

-2.0 

100 

40 


Note 1: These are recommended specifications and the lines are user-defined; it is the user’s responsibility to ensure adequate 
drive. 
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D16 represents a 16-bit expansion module. 

D8/8 represents an 8-bit baseboard that can support 
an 8-bit expansion module. 

D16/8 represents a 16-bit baseboard that can support 
an 8-bit expansion module. 

D16/16 represents a 16-bit baseboard that can support 
an 8- or 16-bit expansion module. 

6.3.2 DMA support 

DMA represents a baseboard or expansion module 
that can support DMA operations. 



Figure 17. Connector pin numbering (top view of baseboard connector). 



COMPONENT SIDE 

NOTES: 1. All dimensions are listed in inches unless otherwise specified. 
2. All tolerances are ± .005" for .xxx and ± .01" for .xx. 


Figure 18. Standard outline for single-wide expansion module. 
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6.3.3 Interlocked operation 

F represents a baseboard that does not support 
interlocked operation (that is, only full-speed 
operations are performed). 

I represents an expansion module that requires 

interlocked operation (that is, requires the 
baseboard to support MWAIT*). 

6.3.4 Examples 

A 16-bit baseboard that supports both 8- and 16-bit 
expansion modules, that has DMA capability, and that 
supports the MWAIT* function would be specified as 
follows: 

P959 I/O Expansion Bus Compliance: D16/16 DMA 
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Table 7. 

Pin assignments. 


Pin 

Mnemonic 

Description 

Pin 

Mnemonic 

Description 

1 

+ 12V 

+ 12 Volts 

2 

-12V 

-12 Volts 

3 

GND 

Signal Ground 

4 

+ 5V 

+ 5 Volts 

5 

RESET 

Reset 

6 

MCLK 

Expansion Module Clock 

7 

MA2 

Address 2 

8 

MPST* 

Expansion Module Present 

9 

MAI 

Address 1 

10 

— 

Reserved 

11 

MAO 

Address 0 

12 

MINTR1 

Interrupt 1 

13 

IOWRT* 

I/O Write Command 

14 

MINTRO 

Interrupt 0 

15 

IORD* 

I/O Read Command 

16 

MWAIT* 

Expansion Module Wait 

17 

GND 

Signal Ground 

18 

+ 5V 

+ 5 Volts 

19 

MD7 

Data Bit 7 

20 

MCS1 * 

Chip Select 1 

21 

MD6 

Data Bit 6 

22 

MCSO* 

Chip Select 0 

23 

MD5 

Data Bit 5 

24 

— 

Reserved 

25 

MD4 

Data Bit 4 

26 

TDMA 

Terminate DMA 

27 

MD3 

Data Bit 3 

28 

OPT 1 

Option 1 

29 

MD2 

Data Bit 2 

30 

OPTO 

Option 0 

31 

MD1 

Data Bit 1 

32 

MDACK* 

DMA Acknowledge 

33 

MDO 

Data Bit 0 

34 

MDRQT 

DMA Request 

35 

GND 

Signal Ground 

36 

+ 5 V 

+ 5 Volts 

37 1 

MD1 4 

Data Bit 14 

38 1 

MD1 5 

Data Bit 15 

39 1 

MD1 2 

Data Bit 1 2 

40 1 

MD1 3 

Data Bit 13 

41 1 

MD10 

Data Bit 10 

42 1 

MD11 

Data Bit 11 

43 1 

MD8 

Data Bit 8 

44 1 

MD9 

Data Bit 9 

NOTE 1: MD8-MD15 used only on 16-bit systems. 

NOTE 2: Signals ending with an asterisk (*) are active-low. Signals ending without an asterisk are active-high. 
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An 8-bit expansion module that does not require the 
MWAIT* line and does not support DMA would be spec¬ 
ified as follows: 

P959 I/O Expansion Bus Compliance: D8 
6.3.5 Compliance marking 

The compliance levels of a product shall be docu¬ 
mented in all product specifications and optionally 
marked on the printed circuit board. 


Appendices A and B are omitted to save space—see 
note following the Table of Contents. 



COMPONENT SIDE 

NOTES: 1. All dimensions are listed In Inches unless otherwise specified. 
2. All tolerances are ± .005" for .xxx and ± .01" for .xx. 

Figure 19. Standard outline for double-wide expansion module. 



NOTES: 1. All dimensions are listed in inches unless otherwise specified. 
2. All tolerances are ± .005 " unless otherwise specified. 


Figure 20. Edge-finger connector specifications. 
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The Object Pascal Architecture provides 22 simple stack instructions which 
enable straightforward compilation of Pascal-like languages. 


A Reduced High-Level-Language 

Instruction Set 


Peter U. Schulthess 


Federal Institute of Technology 
Zurich, Switzerland 


C ompiling high-level-language programs into low- 
level machine code is a complex task. However, it 
can be broken down into smaller pieces if the program is 
first compiled to a suitable intermediate instruction set. 
This intermediate code representation can then be either 
interpreted or further translated to final machine code. 

Machine code can be generated for several different 
computers from a single intermediate representation. The 
Uncol machine 1 was the first proposal for an intermediate 
program representation that would facilitate language 
implementation on different computers. The Pascal 
p-code instruction set 2 was designed for a hypothetical 
stack computer to verify the code generation of a CDC 
Pascal compiler, 3 but then served as a tool for hundreds 
of compiler transportation projects. Such an instruction 
set is closely patterned after the source language to be 
compiled, and the intermediate code generation can be 
kept simple. The Pascal-P compiler is substantially 
smaller and less complex than a compiler for the CDC 
6000 series or for the IBM System 370. 4 


Reducing the complexity of a compiler is worthwhile 
as soon as the cost of the language system approaches the 
cost of the hardware. In some cases a complex compiler 
may not even fit into the small computer and a cross- 
compilation on a different machine becomes necessary. 
As a consequence, it is tempting to build hardware that 
directly interprets such an instruction set if it can be done 
at a competitive cost. Dozens of high-level-language 
architectures have been proposed, simulated, and built in 
the last ten years. 

Optimal instruction encoding. The generated code 
for a language-oriented instruction set is typically two to 
four times more compact than for a conventional register 
instruction set. This situation is frequently reported in the 
literature. 513 

Dense code is achieved by selecting short container 
sizes for frequent opcodes, addresses, and constants. 
Often a single language-specific instruction (LOOP, 
CASE, MARK STACK) performs the work of many pri- 
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mitive instructions. Dense code can lead to faster program 
execution because fewer instruction fetches are required. 

The Burroughs B1700 computer series is dynamically 
microprogrammable and defines a number of different 
instructions sets (S machines). 14 Each one is optimized 
for a particular language or application environment. Very 
compact code is achieved for each language separately. 


Glossary 

The architecture of a computer is its structure as far 
as it is relevant to the compiler. It includes a description 
of stacks, registers, data formats, and instruction for¬ 
mats. On the other hand, it normally ignores aspects 
such as cache memories and instruction overlap. 

P-code is the instruction set of a simple hypothetical 
stack computer that is particularly suitable as a target 
machine for Pascal. Typically, this stack computer is not 
realized as a piece of hardware but rather as an inter¬ 
preter program that runs on another machine. 

Dynamic microprogramming is a technique used to 
alter the microprogram and thereby the instruction set 
of a machine when switching from one program to 
another. 

Lexical levels represent the static nesting of scopes 
in procedures and blocks as it can be determined by the 
compiler. There is a global lexical level and a current 
lexical level. The latter contains the variables, names, 
and temporaries of the currently executing block. 

The display is a table of fixed size containing pointers 
to the start of all currently accessible levels. 

Occurrence designates the position of a variable on 
its lexical level. 

A data segment is collectively formed by the data 
items on a lexical level. 

Code segmentation is a technique used to partition 
the object code of a program into separate segments in 
order to keep only the currently required code segments 
in main memory. 

A data structure is implemented in Pascal as a record 
type or as an array type. The name of the record allows 
us to refer collectively to the fields within the record even 
if these are of different types (elements of an array are 
all of the same type). 

Type descriptors reside in the type table and contain 
the size, type, dimensions, and offset of fields within a 
record. The entries in the type table are typically created 
by the compiler and remain unchanged during the exe¬ 
cution of the program. 

Data descriptors are created at procedure or block 
entry and during manipulation of data. They reside on 
the descriptor stack. Non-self-relative descriptors can 
point to a type descriptor in the type table. 

The heap is a storage area where variables can be 
explicitly allocated and deallocated irrespective of the 
nesting of executing procedures. In Pascal, the data in 
the heap are accessed by pointers and generated by 
the standard procedure NEW. 

Template descriptors are a special kind of non-self- 
relative data descriptor that requires a pointer value from 
the stack to complete the addressing process. Multiple 
instances of a given data type in the heap are all 
accessed through the same template descriptors. 


Other language-oriented instruction sets which yield 
dense object code are described by Best et al., 5 Tanen- 
baum, 12 Wilner, 14 Clark, 15 and Wirth. 16 

Complex vs. reduced instruction set machines. Two 

particularly interesting computer architectures have 
recently been implemented as VLSI circuits. The 
A AMP—Advanced-Architecture Microprocessor— 
developed by Rockwell International 5 is a micropro¬ 
grammed implementation of an elaborate high-level- 
language machine containing 153 different stack instruc¬ 
tions. It is representative of a class of a complex instruc¬ 
tion set machines oriented towards block-structured high- 
level languages. For a microcomputer, the machine also 
exhibits impressive floating-point performance. 

In contrast, the RISC—Reduced Instruction Set Com¬ 
puter—developed at Berkeley 17 is not microprogrammed 
and has only 30 instructions, which operate on a set of 
registers. In the RISC, the chip area that in a complex 
instruction set processor is required to implement the 
microprogram is traded for a large pool of registers. The 
register pool is used in a clever addressing scheme called 
the overlapping register window. The scheme is slightly 
reminiscent of a single run-time stack and contributes 
significantly to the high execution speed of the RISC. 

A heated discussion is currently taking place as to 
whether the cost of implementing a complex instruction 
set can be justified when many of the numerous and com¬ 
plex instructions will be rarely used. It is argued that 
additional instructions require little additional space on 
the chip and share microroutines with the basic instruc¬ 
tions. It is also argued that the complex instruction set is 
justified by the additional program protection and simpli¬ 
fied software it provides, and that these advantages out¬ 
weigh any consideration of “raw” execution speed. 

It is not clear how the RISC would be affected if the 
instruction set were to include floating-point arithmetic. 
(There would be enough free opcodes, at least.) The 
object code for the RISC is less dense than for a typical 
high-level-language machine. 

We admire the astonishing results of modem computer 
architecture and in particular VLSI research. Designs like 
the NS 16032, for instance, are noteworthy. Motivated by 
these results, we present a hypothetical OPA—Object 
Pascal Architecture—as a candidate for a reduced high- 
level-language instruction set computer. With such a 
machine, we hope to combine the advantages of complex 
instruction set computers (CISCs) and reduced instruction 
set computers (of which Berkeley’s RISC is an example). 

The OPA machine 

This article describes the OPA concept and its current 
implementation as a software interpreter. The acronym 
OPA—for Object Pascal Architecture—was chosen 
because OPA is suitable as a target for object code gen¬ 
eration from Pascal-like languages and also because it 
manipulates data objects rather than typeless values and 
machine addresses. 

The OPA machine has been influenced by the B1700 
SDL intermediate architecture in its use of multiple run¬ 
time stacks, data descriptors, and code segmentation. 14 - 18 
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It is more general-purpose, however, and can well support 
most block-structured and strongly typed languages. (We 
aim for support of Ada in the end.) Simple solutions have 
been found to handle structured data. OPA uses a different 
set of run-time stacks than the SDL, and the architecture 
detects most errors connected with uninitialized variables 
and subrange violations. Instead of the approximately 140 
instruction codes in the SDL architecture, the OPA 
machine needs only 22. It is, therefore, a high-level- 
language machine with a reduced instruction set. 

We have written a compiler from Pascal to OPA code 
that consists of only 1900 Pascal statements and compiles 
itself to a total of 7000 instructions and 12.5K bytes of 
OPA code. Most Pascal compilers are between two to ten 
times longer in terms of statements and code size. The 
compiler is described in a separate paper. 19 

The advantages of the OPA are simple code generation, 
extensive run-time checks, and compact object code, par¬ 
ticularly for large programs. These advantages are 
achieved by a somewhat unusual machine structure that 
separates data-descriptive information into static type 
descriptors and lexically allocated data descriptors. 

Data descriptors. We start our description of the OPA 
with the formats of the data descriptors (Figure I). The 
descriptors are 64 bits long and all carry a tag field. Tag 
values between 0 and 5 mark a self-relative descriptor for 
a scalar data item (CHARACTER, INTEGER, REAL, 
SET, . . . ), where the value is stored in the descriptor 
itself. (We adopt the Burroughs terminology of self-rela¬ 
tive and non-self-relative descriptors rather than using the 
words immediate and indirect.) Tag values 5 and 6 are 
reserved for a later extension of the OPA concept to 
include varying-length strings (see again Figure 1). 

A descriptor with a tag value of 7 describes a data item 
that is either an indirectly accessible scalar or a data struc¬ 
ture. Such a non-self-relative descriptor will not hold the 
value of a variable but only its description. The fields in 
a non-self-relative descriptor (tag = 7) carry additional 
information to describe the data structure: 

• The data address points to a location where the actual 
value can be found. The current interpreter uses only 
16 of the 32 address bits. The address designates a 
byte location. 

• The data type index specifies an entry in a separate 
type table where the structure information of the 
record and the array dimensions can be found. 
(Addressing through the type table will be described 
later in this article, under “Type Tables.”) 

• An initialization link permits an initialization test for 
scalar variables that are passed by reference. The link 
points to the original descriptor and its initialization 
status. (See "Initialization Checks.”) 

The descriptor size has been set at 64 bits because this 
is about the minimum word size that allows for a decent 
implementation of the SET OF CHARACTER type. It 
leaves an adequate precision margin for arithmetic oper¬ 
ations and a large address range in the non-self-relative 
descriptor. 

Run-time stacks. The instructions of an executing 
OPA program operate on a set of functionally separate 


run-time stacks. Figure 2 shows the stacks and tables that 
are relevant to the accessing of program data. The run¬ 
time stacks are listed in Appendix B. 

Descriptor stack. The descriptor stack contains a data 
descriptor for each declared variable or type identifier. 
These descriptors are grouped into lexical levels and 
directly stacked on top of each other without an interven¬ 
ing stack mark. The top of the descriptor stack is also 
used during the evaluation of expressions to pass param¬ 
eters to procedures and to return the result of a function 
procedure. There is no separate expression stack. 

Data stack. The data stack contains the values of struc¬ 
tured types like arrays, records, and strings. The internal 
register pointing to the top of the data stack is incremented 
for each lexical allocation of a structured type. The pre¬ 
vious value of the stack pointer is recorded in the allocated 
descriptor as the data address. A suitable piece of the data 
stack is also allocated if a long temporary value is loaded 
onto the descriptor stack during expression evaluation. 
While the descriptor stack contains 64-bit words, the stor¬ 
age allocation in the data stack is currently in 8-bit 
portions. A section of the data stack is used as a heap. 
The management of the heap is left to the language 
implementer. 

Display. Each display entry can point to a currently 
accessible lexical level in the descriptor stack. Strictly 
speaking, the display is not a run-time stack but a table 
whose size can be determined by the compiler. Our imple¬ 
mentation uses a display table with 16 entries. 

A static chain to link the lexical levels could have been 
used as an alternative to a display table. We chose a 
display because it not only offers a means to implement 
the addressing scheme of nested procedures but, in the 
future, will also support the addressing of data segments 
in external modules. This is important because modern 
languages tend to bundle their variables in modules and 
packages rather than in nested procedures. 

Block stack. Recursive activation of a procedure creates 
multiple generations of the same lexical level. Successive 
allocations will overwrite the previous entry in the display 
table. The previous display entries are saved in the block 
stack to permit later reactivation of recursively buried 
procedures. The lexical-level number, the current position 
of the data stack pointer, and a pointer to the top of the 
return stack are also saved to help the GOTO OUT OF 
BLOCK. (See “Control Transfers.”) 


E 

TAG = 0 

(UNUSED) |8-BIT CHARACTER 

E 

TAG = 1 

(UNUSED) 1 16-BIT CARDINAL 

F 

TAG = 2 

60-BIT INTEGER 

E 

TAG = 3 

60-BIT REAL 

E 

TAG = 4 

60-BIT SET 

E 

TAG = 5 

TYPE INDEX 

SUBRANGE LOW I SUBRANGE HIGH 

E 

TAG = 6 

TYPE INDEX 

STRING SIZE 

DATA ADDRESS 

E 

TAG = 7 

TYPE INDEX 

1NIT LINK 

DATA ADDRESS 


0 1 4 16 32 40 64 


Figure 1. Format of the data descriptors (E = empty bit). 
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Figure 2. Structures involved in the data accessing mechanism. 


Return stack. The return stack is not shown in Figure 
2 since it does not participate in the data accessing mech¬ 
anism but contains code addresses only. These addresses 
are pushed on the return stack by a previous procedure 
call, case selection, or program loop. Since the object 
code is structured into code segments, the code addresses 
on the return stack consist of an 8-bit code segment num¬ 
ber and a 16-bit displacement within the segment. 

Addressing of data. The data address in an instruction 
consists of three 4-bit portions and follows the 4-bit 
opcode (Figure 3). Instructions will be discussed in the 
next section. 

Lexical levels. In the data address portion, the field 
number is used only when a field in a record or an array 
element must be selected (see “Field Number”). The lex¬ 
ical-level field selects an entry in the display table and 
therefore the starting point of a group of descriptors. The 
occurrence number then selects a single data descriptor, 
and, in the case of a LOAD VALUE instruction, a copy 
is produced on the stack. 



Figure 3. Data address in a LOAD VALUE instruction. 


The 4-bit fields provide for 15 lexical levels and for 16 
occurrence descriptors on each level. Successive display 
entries are used if the source program declares more than 
16 variables on one level. Typically, three to seven display 
entries will be used for the global level. The intention here 
is to keep a simple and uniform address format and to 
avoid a distinction between LOAD GLOBAL. LOAD 
INTERMEDIATE, and LOAD LOCAL. Our experience 
shows that 15 levels of 16 descriptors are plenty. (For 
pathological cases an escape to 256 levels is possible, as 
indicated in Appendix A.) 

Pointers. Non-self-relative descriptors describe either 
structured variables like arrays and records or variables 
that may be scalar but have been passed as reference 
parameters. 

An obvious choice to implement a pointer addressing 
scheme would be to use non-self-relative descriptors as 
pointers to dynamically allocated structures in a heap. 
Unfortunately, this would require additional instructions 
to manipulate descriptors directly and thus would defeat 
the purpose of the reduced instruction set. Separate 
instructions would be required to load the value of a 
pointer and to load the record being pointed at. 

Our method of pointer addressing is based on the use 
of special template descriptors. These are non-self-rela¬ 
tive data descriptors with a value of zero in the data 
address field. One template descriptor is allocated for 
each declared or implied structured type, but no space in 
the data stack is initially allocated. 

An instruction referencing a template descriptor will 
notice the zero address field and automatically fetch a 
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pointer from the top of the stack. This pointer will nor¬ 
mally resemble a self-relative integer loaded by a previous 
LOAD VALUE instruction. 

The type index field in the descriptor indicates the 
allocated record type and prefixes the actual allocation in 
the heap. This allows for a loose test at run time to deter¬ 
mine that the pointer actually points to a correct alloca¬ 
tion. This test could be made tighter at the expense of 
additional heap storage. 

Type table. Non-self-relative descriptors include a type 
index field that points to a type descriptor in the type 
table. Figure 4 gives the format of the entries in this table. 

The range entry either describes an array dimension by 
its low bound, high bound, and type of array element, or 
it describes the valid range for a subrange type (e.g., AGE 
= — I . . . 110). 

The field entry specifies the size of a record field and 
an eventual field offset within the record structure. The 
field type indicates the arithmetic type of the field (tagO 
. . . tag4) or, if the field is a record structure itself, points 
to another entry in the type table. 

Groups of type descriptors are linked in a tree-like 
fashion, with all fields in a parent record directly linked 
to the immediate parent. The same link field is also used 
to connect the successive range entries of multidimen¬ 
sional arrays. The top entry for an array is always a field 
entry specifying the total size of the array and an offset 
of zero. The link field can link to a type entry up to 127 
locations above. Its first bit indicates whether the entry is 
a range or a field (R = 1/F = 0). 

Variables of the same type share the entries in the type 
table and reduce the required memory space. Our current 
implementation uses a type table that is prepared by the 
compiler and that remains constant during the execution 
of the program. If fully dynamic types are required, the 
type descriptors must be subjected to the same lexical 
mechanism as the descriptors on the descriptor stack and 
the data stack. 

Field number. Creating a descriptor on the descriptor 
stack for each field in a record and for each array dimen¬ 
sion would be too expensive, take too much execution 
time, and soon exhaust the 16 available entries on each 
lexical level. A data descriptor is allocated only for an 
entire record, and all its fields are found via the field 
entries in the type table (Figure 5). The algorithm of this 
walk through the type table is given by the routine 
DESCRIBE in Appendix C. 

In Figure 5, the field A.f3 is accessed by a LOAD 
VALUE instruction. The identifier A.f3 designates the 
third field in the record variable A. The data descriptor 
for A points to entry 23 in the type table. To this value of 
23, the field number from the instruction is added, giving 
a total of 26. 

To address the field A.f3, the machine walks through 
the type table from entry 26 to entry 23, computing the 
address at each step. In our case, only one step is required 
because the field entry for f3 is directly linked to A (like 
all fields on its record level). In the case of nested record 
declarations and multidimensional arrays, several steps 
become necessary. When the machine steps through array 
dimensions, an index is automatically popped from the 
stack and checked against the specified limits. 


Normally, up to 14 distinct field numbers per record 
nesting level are possible, but an escape mechanism per¬ 
mits field numbers up to 255 (see Appendix A). The for¬ 
mat of our type table, together with the field number 
mechanism, can economically represent and access com¬ 
plicated data structures and multidimensional arrays with¬ 
out a complex code generation pattern in the compiler. 
The scheme can be augmented at the expense of some 
extra storage to check for a correct tag field when access¬ 
ing fields in record variants. 

Instructions. The OPA architecture defines 22 instruc¬ 
tions that operate in a straightforward manner on the run¬ 
time stacks. The formats of these instructions are given 
in Appendix A. We can distinguish four categories of 
instructions—those for data manipulation, those for data 
movement, those for data allocation, and those for control 
transfers. 

Data manipulation. There are six instructions for data 
manipulation: 

ADD 

SUBTRACT 

MULTIPLY 

DIVIDE 

MODULO 

COMPARE 

These instructions pop two operands from the top of the 
descriptor stack and push the result back on. For long 
operands that cannot reside in a self-relative descriptor, 
the data stack is also involved. 

OPA instructions are generic in the sense that the actual 
operation is finally determined by the type of operands. 
Depending on the operand tag fields, an ADD instruction 
will produce a floating-point sum, an integer sum, or the 
union of two sets. If an integer is added to a set, then the 
ADD instruction will perform the logical include opera¬ 
tion. We have not implemented all combinations of tag 
fields, but, in principle, a generic ADD instruction far 
exceeding the scope of the Pascal language could be 
defined. One might suggest that the ADD instruction 
would concatenate two character strings if the appropriate 
tag fields were encountered. The COMPARE instruction 
carries a 4-bit compare code specifying a test for equal, 
unequal, less than, and the like. The other instructions are 
self-explanatory. 


RANGE ENTRY: 


R 

LINK 

ARRAY 

TYPE 

LOW BOUND 

HIGH BOUND 

FI 

ILD ENTRY: 

F 

LINK 

FIELD 

TYPE 

FIELD OFFSET 

FIELD SIZE 


01816 32 48 


Figure 4. Type table formats for array dimensions and record fields. 
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VAR A: RECORD 


fl: CHAR: 
f2: INTEGER: 
f3: 0 .. 65535 


END: 


BEGIN 

IF A.f3 ... 


TYPE DESCRIPTOR 
TABLE: 



DATA DESCRIPTOR FOR RECORD A: 



INSTRUCTION 


Figure 5. An example of the use of the field number. 


Data movement. There are five instructions for data 
movement: 

LOAD SHORT CONSTANT 
LOAD CONSTANT 
LOAD VALUE 
LOAD ADDRESS 
STORE 

These instructions load or store data to or from the top of 
the stack, respectively. Characters and short constants 
with a value between zero and 95 are loaded by a one- 
byte instruction (type = 0). The type of other constants is 
indicated by a type index in the LOAD CONSTANT 
instruction, and information such as length is fetched 
from the type table. The actual value of the constant 
follows in line. (Loading a structured constant or one of 
its elements could be implemented in a natural way.) 

LOAD VALUE loads a copy of a variable on the top of 
the descriptor stack and, if necessary, on the data stack. 
For scalar operands, a self-relative descriptor is always 
produced on the stack. The opcode of the instruction is 
followed by a 12-bit data address (see again Figure 3). If 
the field number is not zero, the type table is examined 
and the necessary indices and pointer values are popped 
from the stack. 

LOAD ADDRESS always loads a non-self-relative 
descriptor pointing to the original data or some element 
of it. The init link field in the new data descriptor points 
to the original descriptor. LOAD ADDRESS is mostly 
used to pass reference parameters to procedures and 
WITH clauses. 


The STORE instruction stores the value on the stack 
into the specified data address. Indexing and pointer qual¬ 
ification on the target location are performed if necessary. 
A conversion takes place if, for instance, an integer value 
is stored into a real variable. There is currently only a 16- 
bit format for the LOAD VALUE, the LOAD ADDRESS, 
and the STORE instructions. 

Data allocation. There are four instructions for data 
allocation: 

ALLOCATE VARIABLE 
ALLOCATE TYPE 
MARK STACK 
UNMARK STACK 

These instructions are concerned with allocation and deal¬ 
location of descriptors. The operation code for ALLO¬ 
CATE VARIABLE is followed by a type index. It 
constructs a new data descriptor on the stack according 
to the information it finds in the type table. For records 
or arrays, a portion of the data stack is also allocated. The 
empty bit of the new descriptor is set TRUE. 

ALLOCATE TYPE creates a descriptor on the stack 
for a structured data item. No space is reserved in the data 
stack, and the address field in the descriptor is set to a 
special value of zero. This special data address will indi¬ 
cate to a later addressing cycle that a pointer is needed 
from the stack (see again section headed “Pointers”). Both 
kinds of allocate instructions can, of course, share the 
same type table entries. 

The MARK STACK operation should also be discussed 
under the heading of data allocation. In the OPA archi¬ 
tecture, the stack position must be remembered for the 
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descriptor stack and for the data stack. The stack is always 
marked after the parameters have been loaded and after 
the call. The MARK STACK instruction occurs in the 
body of the called procedure and not at each code location 
from which the procedure is called. This can save many 
instructions. MARK STACK not only preserves previous 
stack pointers but also does a range check and eventually 
converts the procedure parameters to the required type. 

If the stack is marked for a function data segment, then 
the value to be returned on exit from the function is allo¬ 
cated at the bottom of the new data segment, and it is 
addressable from inside the procedure as occurrence zero. 
The stack pointers saved by the MARK STACK instruc¬ 
tion are adjusted in such a way that a later UNMARK 
STACK instruction will leave the function value on the 
stack. The same UNMARK STACK instruction either ends 
a regular procedure or leaves the function value on the stack. 

Control transfers. There are seven instructions for con¬ 
trol transfers: 

CALL 

LEAVE 

LEAVE CONDITIONAL 
SELECT CASE 
FORMAL CALL 
LOOP 
GOTO 

These instructions operate primarily on the return stack, 
which contains return addresses from procedure calls, 
loops, and case variants. Instructions do not directly carry 
code addresses but only indices into the label table (see 
“Label Segments,” below). This simplifies code genera¬ 
tion in the compiler. 

The CALL instruction pushes the next instruction 
address onto the return stack and then branches to the 
location to be called. Lexical-level information and the 
other stacks remain unchanged. FORMAL CALL pops 
an integer value from the stack and interprets it as a seg¬ 
ment number and a label index. This code location is then 
called. 

SELECT CASE pops an argument from the descriptor 
stack. If the argument is within the given range, then an 
element is selected from a list of indices which follow in 
line after the instruction. If the argument is not in the 
range, then the ELSE INDEX is selected. A return address 
is pushed onto the stack, and the selected case clause is 
called just as it would be by a CALL instruction. If the 
value of a selected list index is 255, then the SELECT 
CASE instruction is skipped ( = “no call”). The SELECT 
CASE instruction also implements IF-THEN-ELSE 
statements. 

The LOOP instruction jumps to a given code address 
without touching on lexical levels or the return stack. 
GOTO can go out of loops and blocks and adjusts the run¬ 
time stacks appropriately. Restoring the display after a 
GOTO OUT OF BLOCK is a nontrivial task; it amounts 
to a repeated UNMARK STACK operation until the 
desired lexical level is found on the block stack. The 
return stack and the program counter are then adjusted 
with the help of a special field in the block stack. With a 
static chain instead of a display table, the GOTO OUT 


OF BLOCK would have been simpler. 

The LEAVE instruction pops a return address and uses 
it as such. It might leave a program loop or an ELSE 
clause. No adjustment of the lexical level is done. 

LEAVE CONDITIONAL pops an argument from the 
descriptor stack and performs a LEAVE operation if the 
popped argument was TRUE. 

Object code structure 

Code segments. A segment contains the code of one or 
more procedures or modules. Program code is organized 
into several logical segments. A virtual memory mecha¬ 
nism is implemented so that only the segments belonging 
to the working set must actually remain in memory. The 
presence of a code segment needs to be checked only by 
the control transfer instructions, which amount to 24 per¬ 
cent of all instructions. The associated overhead for the 
code address translation in the interpreter is small. 

Label segments. Each code segment has its own label 
segment with up to 255 label entries. Each entry consists 
of a code segment number and a displacement within the 
segment (Figure 6). 

The control transfer instructions do not have in-line 
code addresses but rather indices into the label table for 
the current segment. These indices are usually 8 bits long 
and create the restriction of 255 label entries per segment. 
The 8-bit label indices are convenient because they result 
in short selection lists in the SELECT CASE instruc¬ 
tion. Furthermore, the code generator always knows the 
size of the branch addresses in the instruction format, even 
for forward-referenced locations. No sophisticated 
address fix-up is required. 

It is possible—but rare—that the same target code 
location will be referenced by several label entries in dif¬ 
ferent segments, creating redundant label table entries. 
On the other hand, several instructions will often make 
use of the same entry in the label table. This is an instance 
of information sharing analogous to the situation in which 
several data descriptors share the same type table entries. 
In our compiler, one label entry is referenced by 2.6 
instructions. 

Suboptimal encoding. Most language-oriented instruc¬ 
tion sets achieve dense code through a frequency-depend¬ 
ent encoding of instructions and instruction groups. In 
particular, the frequency of small constants and short 
addresses is considered. 

To avoid a proliferation of opcodes, we chose a subop¬ 
timal instruction encoding (see again Appendix A). But 
even with such an encoding, we can nevertheless achieve 
good code density through an appropriate choice of run¬ 
time organization and instruction semantics. Some Pascal 
program fragments and the resulting code sizes are shown 
in Table 1. The corresponding instruction sequences are 
given in Appendix D. 

The examples in Table 1 and in Appendix D clearly 
show that our choice of a single 12-bit data address format 
consisting of field number, occurrence number, and lexi¬ 
cal level is suboptimal. The LOAD VALUE, the LOAD 
ADDRESS, and the STORE instructions are 16 bits long 
even when a local variable can be accessed with a short 
offset. However, even with our 12-bit data address, we 
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obtain competitive code density (see examples discussed 
in "Code Density,” below). 

Since our 12-bit address also contains an eventual field 
number, we can only use a short address format when the 
variable is addressed through field number zero and when 
it is on the local level. We were surprised to find that fewer 
than 25 percent of all data addresses in our programs were 
candidates for a short address format. 

To anyone who needs maximum code density at the 
expense of a more complicated instruction set, we suggest 
two alternatives: 

• The LOAD SHORT CONSTANT instructions from 
48 to 95 can be replaced by short variants of LOAD 
VALUE, LOAD ADDRESS, and STORE, each car¬ 
rying only a 4-bit occurrence number into the current 
lexical level. The short encoding of 48 to 95 does not 
pay off anyway. 

• A context-dependent encoding of the data address can 
be introduced in spite of the resulting problems for 
the debugger. The interpreter will first consider the 
lexical level. If the indicated level is greater than the 


currently active one, the value is considered as an 
occurrence indication on the current level (occurrence 
lexiclevel — currlev). A further context depend¬ 
ence can be introduced by providing the field number 
only if a non-self-relative descriptor is accessed (~40 
percent of the data addresses). This is possible 
because the compiler can always determine whether 
a descriptor will be self- or non-self-relative. 

We do not recommend either of the above alternatives, 
however, but prefer our original scheme because it is eas¬ 
ier to understand and to implement. 

The last statement of Table 1 is an example in which 
the OPA machine allows for particularly elegant and com¬ 
pact code. The detailed code pattern for the CASE state¬ 
ment is given in Appendix D. We capitalize on the fact 
that in the OPA machine a case selection is consistently 
patterned after the procedure call. A short case list is 
achieved, and the procedure is called in one step instead 
of two. This also saves return stack space. Incidentally, 
the same benefits and code generation patterns arise in 
the IF-THEN-ELSE constructions. 


CODE SEGMENTS 

0 TO 65535 BYTES OF CODE EACH 


LABEL TABLES 

0 TO 255 LABEL ENTRIES EACH 


a 

BYTES OF CODE 


SEGMENTS 


LABEL ENTRIES 

V 


1 TO 256 SEGMENTS 


Figure 6. Code and label segments. 
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Run-time checks 

Array bound checks. Array bound checks are per¬ 
formed during the type table walkthrough and do not 
require explicit check instructions in the code. Whenever 
a subscript is popped from the stack, it is checked against 
the low and high bounds in the type table entry. If the low 
bound is not zero, then its value is subtracted from the 
subscript. The subscripts of a multidimensional array are 
checked individually. If the size of an array element is not 
one, the subscript is multiplied by the size of the array 
element. 

Range checks. The range entries in the type table nor¬ 
mally specify an array dimension. They can, however, 
represent the permissible range of a subrange variable or 
of an enumerated type. A non-self-relative descriptor 
pointing to this range entry will then be allocated for the 
variable instead of a self-relative one. This method of 
range checking will eventually be implemented by a com¬ 
piler option and will require additional functionality in 

the interpreter but no further instructions. Currently, the 
self-relative descriptors only limit (and trap) their values 
to 0...255, to 0...65535, or to a signed 60-bit value. 

Initialization checks. The initialization status of a vari¬ 
able is indicated by the first bit in the tag field—the 
empty bit. This bit is set to TRUE when the descriptor is 
allocated but not yet given a value. A later assignment 
will reset the empty bit. The empty bit mechanism catches 
all attempts to load an uninitialized scalar. For an array or 
a record structure, there is only a single empty bit. It 
indicates that none of the components have yet been 
assigned a value. A value of FALSE leaves open the pos¬ 
sibility that some elements have remained uninitialized. 
Since one single descriptor is allocated for an array or a 
record variable, we can only check if at least one of the 
array elements or record fields has a defined value. This 
makes for an incomplete initialization test in the case of 
arrays and records. 

The self-relative data descriptors deal only with the 
empty bit. Non-self-relative descriptors also contain an 
initlink field that points either to their own descriptors or 
to previous descriptors. This permits a similar initializa¬ 
tion test even for indirectly accessed data. Instead of test¬ 
ing the empty bit of the descriptor being accessed, the 
interpreter tests the empty bit of the descriptor pointed at 
by the initlink. An initlink to a previous descriptor will 
normally be set up when a LOAD ADDRESS instruction 
loads a reference to a previous allocation or a field thereof. 

Exceptions. If a run-time error is detected, label 0 of 
the current segment is called with the type of the error as 
a parameter. This label entry then calls an error handler 
that may write a memory dump to disk, go into an inter¬ 
active debugging mode, or simply ignore the exception. 
The action of the error handler in the run-time system is 
beyond the scope of the OPA machine. Asynchronous 
events from peripheral devices can be similarly treated as 
accidental procedure calls. 

Evaluation 

Code density. To obtain a measure of OPA code den¬ 
sity, we have compiled the widely circulated puzzle pro¬ 


gram by Forest Baskett (which is reproduced in Jacobi 7 ) 
and about half of the OPA compiler (scanner and initial¬ 
ization) on several machines. The results are given in 
Table 2. The values include storage for string templates, 
label tables, and type descriptors. The puzzle program is 
given in two versions: version A is the original, and in 
version B the triple FOR loops in the initialization 
sequence have been turned into a functionally equivalent 
procedure. 

In the OPA, 40 percent of the table space is for type 
table entries and 60 percent for the label tables in each 
code segment. Carrying the descriptors along is justified 
because of the increased flexibility in the data formats. 
The fact that we use a rather crude instruction encoding 
does not prevent us from achieving dense code. Both the 
UCSD machine and the M code machine manipulate 16- 
bit units. Set operations that the M code was unable to 
handle were commented out in the last program. This has 
further reduced the M code size. Including the check 
instructions would add about 17 percent to the IBM 370 


Table 1. 

Object code for Pascal fragments 
(no checks, short local addressing). 



OPA CODE* 

UCSD 

PASCAL^ 

M CODE'S 

IBM 370 4 

ch:= 0 ; 

= 3 BYTES = 

3 BYTES 

= 2 BYTES 

= 6 BYTES 

ch:= 1 

= 3 BYTES = 

3 BYTES 

= 3 BYTES 

= 8 BYTES 

A.f3: = i; 

= 4 BYTES = 

5 BYTES 

= 3 BYTES 

= 8 BYTES 

proc2(i ,3); 

= 4 BYTES = 

4 BYTES 

= 3 BYTES 

= 20 BYTES 

IF ch<’ 'THEN 

procl: 

= 7 BYTES = 

7 BYTES 

= 7 BYTES 

= 16 BYTES 

CASE i OF 

0,2,4,6: prod; 

1,3,5,7: proc3 

END; 

= 10 BYTES = 

31 BYTES 

= 23 BYTES 

= 64 BYTES 


Table 2. 

Compilation of complete programs 
(check instructions omitted). 



OPA CODE* 

UCSD 

PASCAL' 5 

M CODE' 5 

IBM 370 4 

PUZZLE-PROGRAM A 

CODE BYTES 

1240 

2498 

1310 

-4804 

TABLES 

284 

50 

92 

-164 

TOTAL 

1524 

2550 

1402 

4968 

PUZZLE-PROGRAM B 

CODE BYTES 

731 

1145 

755 

-2390 

TABLES 

189 

60 

94 

-168 

TOTAL 

920 

1205 

849 

2584 

OPA COMPILER 
(-50%) 

CODE BYTES 

6217 

7903 

6142 


TABLES 

1296 

1030 

680 


TOTAL 

7513 

8930 

6822 

17256 
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code, about 10 percent to the UCSD Pascal p-code, about 
5 percent to the M code, and zero percent to the OPA 
code. 

Branching is efficient in terms of code density when a 
code location is called from several places. The entry in 
the label table can then be shared. Otherwise, the addi¬ 
tional overhead for the 8-bit label index must be paid. 
Significant economies in code space occur in CASE state¬ 
ments that have long case lists with many elements refer¬ 
ring to the same label. 

The OPA architecture favors a programming style with 
many procedures that directly manipulate their parameters 
rather than local auxiliary variables. Access to local vari¬ 
ables is not as profitable as in other machines. No short 
instruction formats that would warrant the allocation of 
these locals are currently available. 

Code segmentation also contributes to an efficient uti¬ 
lization of the code space because only the working-set 
segments must remain in memory. This aspect is not rep¬ 
resented in Table 2. The OPA compiler would discard its 
initialization segment of 2.5K bytes. 

Data packing. Arguments favoring high code density 
are somewhat weakened by the decreasing cost of primary 
and secondary memory. Often, more memory will be 
required for storing data than for storing code. An instruc¬ 
tion set should therefore economically handle and store a 
large variety of data formats and not just “words.” 

A bit-addressable instead of a byte-addressable OPA 
machine would use the same descriptor mechanism and 
the same instructions. Whereas direct addressing to the 
bit level is complicated on a 16-bit machine, it would 
present no problems with a 32-bit address in the non-self- 
relative descriptor. (The 64-bit descriptor could be 
squeezed to accommodate even a 48-bit address.) Mem¬ 
ory access at the bit level is attractive for raster-scan dis¬ 
plays. Current personal computers with raster-scan 
displays use either microprogrammed bit map instructions 
or a dedicated display processor. 

The space taken up by non-self-relative descriptors in 
the descriptor stack is typically less than 6 percent of the 
whole data area, and these descriptors usually share many 
common entries in the type table. About 80 percent of the 
data area is spent on the data stack for allocating records 
and arrays (but not their descriptors). The space for 
descriptors in many cases is compensated for by a better 
memory allocation scheme for large data structures. 

However, we worry more about the memory manage¬ 
ment problem created by the multiple run-time stacks than 
we do about extra space required for data and type descrip¬ 
tors. This memory management problem will eventually 
go away in machines with virtual memory systems. For 
the moment, we keep all stacks except the descriptor and 
the data stack movable. However, as soon as there are 
multiple processes in a machine, even one with a virtual 
memory system, the memory management problem will 
reappear. 

Execution speed. We currently have an interpreter for 
OPA code written in Modula-2. Our purpose in develop¬ 
ing this interpreter was to provide a tool for verifying the 
function of the OPA architecture. It runs on a 6-MHz 
MC68000 and on the Lilith Modula machine 16 and has 


an average instruction execution time of a little less than 
500 microseconds on both machines. 

This is clearly an unacceptable execution speed, and 
we should write an interpreter in assembly language so 
that the various registers and stack pointers of the virtual 
machine can be kept in real registers and not in memory. 
On a 10-MHz MC68000, we expect an average instruction 
execution time of around 40 microseconds. When emu¬ 
lated on a 16-bit machine, the 64-bit-wide descriptor stack 
requires many more memory accesses than an intrinsic 
16-bit architecture. The number of memory accesses to 
the type table, however, remains relatively small because 
only about 10 percent of all instructions access the type 
table. The reason for the long execution time is primarily 
the large stack word and not the descriptor indirection. 
The time might be improved in a future version of the 
interpreter that would not always write all 64 bits. 

In a hardware OPA machine, the 64-bit stack word 
might be squeezed down to a 32-bit word and the topmost 
stack locations could be kept in processor registers. 
A sophisticated OPA machine might overlap the exe¬ 
cution of several instructions. Here, the separate run-time 
stacks and a read-only type table might be of some help— 
an instruction stepping through the type table would not 
fear a “last-minute” modification of the type entries. 
Instructions like CALL, LEAVE, and LOOP would han¬ 
dle their return addresses on the separate return stack and 
would not need to watch for an eventual push or pop by a 
previous incomplete data instruction, as might occur in a 
machine with a single stack. 

Simplicity of the instruction set. We have substan¬ 
tially simplified the instruction set of a high-level-lan¬ 
guage machine and its encoding and have still achieved 
good code density. By introducing additional instructions, 
we could achieve even denser code, but we prefer to keep 
the instruction set in its simple form. 

With the OPA, we hope to create an abstract view of a 
machine that is close to the programming language. One 
should be able to understand the semantics of the instruc¬ 
tions without a detailed knowledge of what is happening 
in the micromachine. Since the functions are separated 
out into different stacks, they can be contemplated 
separately. 

The reduction of the instruction set has shifted some of 
the burden from instruction processing to descriptor pro¬ 
cessing. This complexity appears in the interpreter routine 
DESCRIBE (see again Appendix D), which steps through 
the type table and also does the range checking. This 
routine consists of 18 statements. Additional complexity 
is also introduced in the arithmetic instructions, which 
must take into account the type of their operands. In our 
interpreter, this means a tedious extraction of 4-bit fields. 
In a hardware implementation, control signals for the 
ALU would not be derived from the opcode as usual, but 
rather from the tag fields of the operands. 

The current OPA interpreter is 3100 bytes long on a 
Lilith personal computer. 16 Our next step will be to assess 
the complexity of an eventual hardware realization and 
the achievable speed. The small Pascal compiler we have 
written to generate OPA code indicates that code genera¬ 
tion for the OPA is indeed simple. 
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H igh-level-language mechanisms can be implemented 
with a few simple instructions. We avoid the pro¬ 
liferation of opcodes that is traditionally introduced to 
achieve good code density. In addition, our high-level- 
language machine performs extensive run-time checks on 
the executing program and still allows for very compact ob¬ 
ject code. From a subjective point of view, we feel that the 
Object Pascal Architecture and its formats are clean and 
concise. The functionality achievable within the OPA ex¬ 
tends far beyond the semantics of the Pascal language. We 
have implemented Pascal mainly for reasons of compiler 
simplicity. 

The present implementation also proves that stack- 
oriented instruction sets can give very compact object code 
if a complete program—and not just the evaluation of 
arithmetic expressions—is considered. Arguments for 
and against the optimality of stack instruction sets are 
abundant in the literature, 8 ' 10 -' 2 ' 20 but these arguments 
are not always based on sufficiently large and realistic 
program samples. ■ 
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Appendixes 


A: Format of the OPA instructions (hexadecimal) 


LOAD SHORT CONSTANT 

LOAD CONSTANT 

COMPARE 

MARK STACK 

LOAD VALUE 

LOAD ADDRESS 

STORE 

SELECT CASE 

CALL 

ALLOCATE VAR 
ALLOCATE TYPE 
LOOP 
GOTO 
LEAVE 

LEAVE CONDITIONAL 
UNMARK STACK 
ADD 

SUBTRACT 
MULTIPLY 
DIVIDE 
MODULO 
FORMAL CALL 


00..5F 


6, 0..F* (typespec), value 

7, 0..F* (comparecode) 

8, 0..F* (lexlev), 0..D {parmcode}, 

9, 0..F* (lexlev), 0..F (occurrence), 

A, 0..F* (lexlev), 0..F* (occurrence), 

B, 0..F* (lexlev), 0..F (occurrence), 

C, 0..F* (listsize),00..FFfelse index), 

D, 0..F* (labelindex) 

E, 0..F* (typespec) 

FI, 00..FF(typespec) 

F2, 00..FF(labelindex) 

F3, 00. FF(labelindex) 


E..F (funccode) 
0..F* (fieldnum) 
0..F* (fieldnum) 
0..F* (fieldnum) 
00. FFfcaseindex} 


F4 

F5 

F6 

F7 

F8 

F9 

FA 

FB 

FC 


{...} stands for a repetitively occurring field 
(...) only explains the parameter to the left of it 

F* indicates an escape mechanism: 

if the value is 15 decimal then the whole next byte is used instead 
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B: Run-time structures 



CONTAINING 

SIZE 

DESCRIPTOR STACK 

DATA DESCRIPTORS 

64 BITS 

DISPLAY TABLE 

POINTERS TO LEXICAL LEVEL 

16 BITS 

DATA STACK 

ARRAYS, RECORDS, STRINGS 

8 BITS 

BLOCK STACK 

BURIED STACK POINTERS, LEVEL INDEX 

48 BITS 

RETURN STACK 

PROCEDURE- AND LOOP RETURN ADDRESSES 

24 BITS 

TYPE TABLE 

TYPE DESCRIPTORS 

48 BITS 

CODE SEGMENTS 

INSTRUCTIONS 

64K BITS 

LABEL TABLES 

PROCEDURE- AND LOOP ADDRESS 

24 BITS 


C: The stepping mechanism through the type table 


PROCEDURE describe; 

f* performs a typetable walk and leaves a description of the •) 
(* variable in elemtype, eltsize, name.addr •) 

BEGIN endtype := name.typeinx; 

begintype:= endtype+fieldnum; 
tvpeentry:= typetable[ begintype ]; 
elemtype := typeentry.typeinx; 
eltsize := typetable[ elemtype ].size; 

REPEAT (* one step *) 

IF typeentry.1ink>127 

THEN (* array •) BEGIN 
indexpop; 

boundcheck( typeentry, index ); 

step := eltsize*(index-typeentry.Ibnd) 


ELSE (• record *) BEGIN 

step := typeentry.offset; 
eltsize:= typeentry.size 

END; 

name.addr := name.addr+step ; 
begintype := begintype- typeentry.link 

UNTIL endtype=begintype 

END (* describe *); 
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D: Code generation pattern for some Pascal program fragments 
(no checks, short local addressing) 


OPA CODE* 

UCSD PASCAL 15 

M CODE 16 

IBM 370 4 

ch:= 0; 

LDSHC 0 

SLDC 0 

Llx 0 

XR RIO,RIO 

ST 0,occ,11 

STL occ 

SLWx occ 

ST RIO,occ,11 

= 3 bytes 

= 3 bytes 

= 2 bytes 

= 6 bytes 

ch:= ' 1 ; 

LDSHC 32 

SLDC 32 

LIB 32 

LA RIO,32 

ST 0,occ,11 

STL occ 

SLWx occ 

ST RIO,occ,11 

= 3 bytes 

= 3 bytes 

= 3 bytes 

= 8 bytes 

A.f3: = i; 

LODV 0,occ(i),11 

SLDL occ(A) 

LLWx occ(A) 

L R10,occ(A),11 

ST 3,occ(A),11 

IND 4 

LLWx occ(i) 

ST R10,occ(A + 8), 

SLDW occ(i) 

STO 

SSWx 4 



= 4 bytes 

= 5 bytes 

= 3 bytes 

= 8 bytes 

proc2(i,3); 

LODV 0,occ(i),11 

SLDW occ(i) 

LLWx occ(i) 

L R10,occ(i),11 

LDSHC 3 

SLDC 3 

LI3 

ST R10.5.R8 

CALL proc2 

CLP p2 

CL. p2 

LA RIO,3 

ST R10.6.R8 

BALR R9,R1 ; pi 

= 4 bytes 

= 4 bytes 

= 3 bytes 

= 20 bytes 

IF ch< 1 1 THEN procl; 

LODV 0,occ(ch),11 

SLDL occ(ch) 

LLWx occ(ch) 

L R10,occ(ch),11 

LDSHC 32 

SLDC 32 

LIB 32 

C R10,( 1 ■) 

CMPR LESS 

LESI 

ULSS 

BGEQ else, R14 

SLCT 2,pi ,255 

FJP else 

JPFC else 

BALR R9.R1 ; pi 

CLP pi 

CLx pi 



'else 

'else 

'else 

= 7 bytes 

= 7 bytes 

= 7 bytes 

= 16 bytes 


CASEi OF 


0,2,4,6: procl; 
1,3,5,7: proc3 
END; 


LODV 0,occ(i),11 

LSDL 

occ(i) 

LLWx 

occ(i) 

L 

R10,occ(i),1 

SLCT 10,255, 

XJP 

0,7,else 

ENTC 

size, 

B 

,jtab 

pi ,p3 


c1,c2, 


lo.hi. 

'cl 


pi ,p3 


cl,c2, 


c1,c2, 

BALR 

9,1 ; Pi 

pi ,p3 


cl,c2, 


cl,c2, 

B 

out 

pi ,p3 


c1,c2, 


cl,c2, 

*C2 






c1,c2 

BALR 

9,1 ; p3 






B 

out 


'cl 


'cl 


*jtab 



CLP 

Pi 

CLx 

Pi 

SLL 

10,2 


UJP 

out 

EXC 


B 

else 


*c2 


*c2 


B 

cl 


CLP 

p3 

CLx 

P3 

B 

c2 


UJP 

out 

EXC 


B 

cl 






B 

c2 






B 

cl 






B 

c2 






B 

cl 






B 

c2 

= 10 bytes 

= 31 bytes 

= 23 bytes 

= 64 bytes 
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Computer scientist forecasts significantly faster and cheaper 
computer systems by the end of the decade 


By the end of the 1980s, computers will 
be cheaper and faster, will contain chips 
that can hold millions of transistors, and 
will have memory capabilities that out¬ 


distance by a factor of 10 the systems 
presently used, according to John Hen- 
nessy, associate professor of electrical 
engineering at Stanford University. “Peo¬ 


ple will be able to buy machines for 
$3000-54000 that are faster than machines 
that now cost $200,000,” he predicts. 

Personal computers will be consider¬ 
ably more powerful and able to perform 
many tasks that are currently associated 
with minicomputers, while the bigger 
machines available to scientists and engi¬ 
neers will become significantly faster-“as 
fast as a Cray,” says Hennessy. 

“The smaller machines already are 
rivaling the larger computers. There will 
be more computer power available for less 
cost, and people are going to see an order- 
of-magnitude increase in computer speed. 
Very low cost computers will be made, 
consisting of only a few chips, much as the 
digital watches of today use a single chip. 
The selling price of such computers will be 
determined by the physical packaging, not 
the electronics,” Hennessy notes. “Very 
large scale integration will allow the cost- 
effective construction of special-purpose 
hardware for functions such as speech in¬ 
terpretation, graphics, and robotics.” 

Hennessy is one of eleven Stanford 
science and engineering faculty recently 
named presidential investigators by the 
National Science Foundation, an honor 
that can bring up to $500,000 of research 
funds for each recipient. Hennessy is also 
project director for MIPS—Micropro¬ 
cessor without Interlocked Pipe Stages— 
the new 32-bit microprocessor that was 
completely designed and fabricated at 
Stanford. 

MIPS represents a new architecture, 
housing only 25,000 transistors as com¬ 
pared with the 100,000 or more transistors 
usually needed in 32-bit machines. Its real 
strength, says Hennessy, is that it outper¬ 
forms commercially available micropro¬ 
cessors by about a factor of five. Hen¬ 
nessy is trying to increase the performance 
of MIPS “by a factor of five to 10,” 
which would make it faster than any ex¬ 
isting machine—except for today’s super¬ 
computers. 

The increased speed was achieved on 
MIPS by 



John Hennessy (center) of Stanford headed the project that developed MIPS, a high- 
performance microprocessor requiring only 25,000 transistors, to implement a full 32-bit architec¬ 
ture. Hennessy, who was a member of IEEE Micro's first editorial board, is now working on fur¬ 
ther performance improvements for MIPS. 
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• improving the compiler technology 
that translates languages such as For¬ 
tran or Pascal into computer instruc¬ 
tions; 

• redesigning the architecture so that it 
would be more compatible with the 
compiler and integrated-circuit 
technology; and 

• devising a chip that relies less on 
read-only memory (ROM) and in¬ 
stead uses as many transistors as 
possible to increase instruction ex¬ 
ecution and speed. 

Some commercial chips now contain as 
many as 450,000 transistors, but 80 per¬ 
cent of these are in ROM. MIPS has 
25,000 transistors, but only 15 percent of 
them are in ROM. This allows for a much 


faster system, with more chip area 
devoted to active operation. 

The system is designed to let the com¬ 
piler do most of the translation work, a 
feature that commercial systems do not 
have. Most systems do the instruction in¬ 
terpretation as the program is executing. 
“The instructions MIPS receives are very 
simple, which means the machine can 
function faster. VLSI systems produced 
by Intel or Motorola have more com¬ 
plicated instructions, and it takes longer 
to execute them,” Hennessy explains. 

In order to produce a new system that is 
faster by a factor of five or 10, he is study¬ 
ing the current design of the system to see 
where the bottlenecks are. In an effort to 
develop a new architecture for the 32-bit 
microprocessor, he is working closely with 


New Editorial Board members announced 


Two new members of the IEEE Micro 
Editorial Board have been announced by 
Editor-in-Chief Peter Rony. They are 
James J. Farrell III of Motorola in 
Austin, Texas, and Richard H. Stern, an 
attorney in Washington, DC. 

Farrell is manager of technical com¬ 
munications for Motorola MOS In¬ 
tegrated Circuits Group. Before coming 
to Motorola, he spent 10 years with 
Electronic Associates, Inc., working in 
analog/hybrid computer development. 
Earlier, he worked on hybrid ICs and 
power transistor applications for Bendix 
Semiconductor. He has published widely 
in the US and abroad. 

Farrell graduated from the US Armed 
Forces Institute in Tokyo. 

Stern specializes in the fields of in¬ 
tellectual property and antitrust law. He 
was formerly chief of the Intellectual 
Property Section of the Antitrust Divi¬ 
sion, US Department of Justice, where 
he was responsible for preparing the 
government’s submissions to the 



Richard H. Stern 

Supreme Court in a number of cases in¬ 
volving the patentability of computer 
programs. 


Competition heats up in microsoftware operating system arena 


International Data Corporation’s 
recently published report, Trends in 
Micro Software Operating Systems, 
reveals keen competitive struggles ahead 
in the microsoftware operating systems 
market. 

Though the market for transportable 
operating systems on microcomputers 
has been dominated by Digital Re¬ 
search’s CP/M in the 8-bit environment 
and by Microsoft’s MS-DOS in the 
16-bit environment, recent hardware 
technological advances, changing user 
demands, and new players have altered 
the picture dramatically. 


In recent announcements, both AT&T 
and IBM have declared intentions to 
compete more directly in the microsoft¬ 
ware operating systems field, and now 
Unix looms in importance. AT&T’s 
move to take stronger control of the 
licensing and marketing of Unix and 
Unix-related products, especially for per¬ 
sonal computers, and IBM’s announce¬ 
ment that it will support its own version 
of Unix, has strengthened the potential 
for Unix penetration in the PC environ¬ 
ment. 

The IDC report focuses on the achieve¬ 
ments thus far of the major vendors in 


Stanford’s Integrated Circuits Laboratory 
to incorporate any new technology that 
may develop there. The new chip will have 
between 100,000 and 150,000 transistors, 
50 percent of which may be in memory, 
according to Hennessy. “We also are try¬ 
ing to determine whether we should sup¬ 
ply support for such things as multiplica¬ 
tion and floating-point operations on or 
off the chip,” he notes. The more data 
that can be stored on the chip itself, the 
faster the chip will be. If information is 
stored on an adjacent chip, it takes con¬ 
siderably more time to retrieve it. 

Hennessy and his associates received a 
three-year, $5.7 million grant from the 
Defense Advanced Research Projects 
Agency in June 1983 to fund their 
research. 



James J. Farrell III 


He received a BSEE from Columbia 
University in 1954 and an LLB from Yale 
Law School in 1959. 


creating the generic micro operating 
systems market, in fostering the porta¬ 
bility of software, and in aiding the 
leveraging of resources committed to the 
acquisition and development of applica¬ 
tions software by both end users and 
software developers alike. 

In 62 pages, the report 
• describes the evolution of micro 
operating systems from the perspec¬ 
tive of the current dominant 
players, Digital Research and 
Microsoft; 

cont'd on page 71 
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microLAW 


by Richard H. Stem 

Law Offices of Richard H. Stern 
2101 L Street NW, Suite 800 
Washington, DC 20037 


Chip copyright protection 

Both houses of Congress have deter¬ 
mined that semiconductor chips should 
be protected against “chip piracy,” but 
they have selected different preferred 
means of doing so. The Senate has 
passed S. 1201, the Semiconductor Chip 
Protection Act of 1984, an amendment 
to the federal Copyright Act (17 U.S. 
Code, Chapters 1-8). The House opted 
for H.R. 5525, a separate, self-contained 
law that is outside the Copyright Act, 
although it is in many ways similar to 
copyright law. A conference between 
Senate and House lawmakers will now 
attempt to reconcile the two bills. It is 
anticipated that a compromise version of 
the legislation will be hammered out and 
enacted into law later this year. 

The Senate and House chip bills are 
both directed to “mask works,” a con¬ 
cept they each use that refers to the 
shapes, patterns, or “topography” of 
the various layers of a chip. Both bills 
protect mask works for 10 years and give 
the owner the right to exclude others 
from reproducing the work (in a data¬ 
base tape, mask, or ship); selling or im¬ 
porting chips embodying the work; and 
inducing others to do the foregoing. (The 
House bill does the latter explicitly, and 
the Senate bill does so by implication.) 
Both bills expressly immunize reverse 
engineering and make one or another 
special provision for innocent infringe¬ 
ment. 

As originally introduced, the Senate 
and House bills both had compulsory 
licensing provisions, but neither does any 
longer. The term “compulsory licens¬ 
ing” alarmed many companies, largely 
ones outside the semiconductor industry. 
Therefore, the compulsory licensing pro¬ 
visions were eliminated from each bill 
and provisions were substituted that 
limited the liability of so-called “in¬ 
nocent infringers” to payment of a 
reasonable royalty as to infringing chips. 
The House bill permits a purchaser, such 


as an equipment manufacturer, to use up 
all chips that he purchased before he 
learned that the chip was protected under 
the Act. But once that inventory is used 
up the manufacturer can no longer utilize 
the chip (unless he purchases it from the 
mask work owner or his licensees). The 
innocent purchaser is not liable for chips 
sold (for example, as part of equipment) 
before the purchaser learned of the mask 
work owner’s rights, but he must pay a 
reasonable royalty on chips he so utilizes 
after he acquired notice of the mask 
work rights. The Senate bill goes further 
in the purchaser’s favor. It allows him to 
continue to use such chips in his equip¬ 
ment on a reasonable royalty basis even 
after his existing inventory is exhausted, 


“Mask works”—the shapes, 
patterns, or topography of the 
various layers of a chip—are 
now protected by federal law. 


if the “equities” of the case favor him 
—for example, if the equipment is a 
microcomputer laboriously designed 
around that particular chip. Moreover, 
the Senate bill allows such a purchaser to 
make or buy the chip in the future, again 
on a reasonable royalty basis, if the mask 
work owner and his licensees cannot or 
will not supply the chip at a reasonable 
price. It is understood that the House 
version is the more likely to be enacted, 
insofar as this issue is concerned 

Under both bills, the similarity between 
two chips must be quite close for the sec¬ 
ond chip to be considered an infringement 
of the first. Both bills contemplate exten¬ 
sive use of expert testimony in determin¬ 


ing whether there is an infringement. Both 
contemplate that functionally dictated 
chip configurations shall not be protect¬ 
able. Both suggest, also, that “cells” 
within chips may be protectable. 

Antitrust exemption for R&D 
joint ventures 

Another piece of pending of legislation 
of interest to the high-technology com¬ 
munity is the antitrust exemption measure 
for R&D joint ventures. Both Senate and 
House bills have as their centerpiece a dec¬ 
laration that R&D joint ventures shall not 
be considered “illegal per se” under 
federal or state antitrust laws. Exactly 
what this declaration means is unclear, 
particularly since no judicial decisions 
have thus far stigmatized any R&D joint 
ventures as illegal per se. However, the 
many supporters of the legislation believe 
that R&D joint ventures will be encour¬ 
aged by a signal of congressional ap¬ 
proval— so that the legislation will serve 
an important symbolic function. Another 
feature of the legislation is to eliminate 
treble damage liability in antitrust suits 
brought against the joint venture, and to 
permit injured parties to recover only 
single, actual damages. Probably, this 
limitation on liability will apply only to 
joint ventures disclosed to the govern¬ 
ment, but this issue is still open. 


ROM-less Apple clones 

In an interesting pair of developments, 
the U.S. International Trade Commission 
and the Treasury Department’s Customs 
Service have reached opposite conclusions 
as to their respective powers to exclude 
from import or entry into the United 
States ROM-less “Apple clone” micro¬ 
computers, such as the Orange or Pineap- 
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pie. Far East manufacturers of these 
microcomputers have taken to shipping 
them to the United States without ROMs, 
to avoid having them barred from entry 
into the United States on the ground that 
they contain object code copies of soft¬ 
ware protected under Apple’s copyrights 
on its operating system software. Once the 
microcomputers are in the United States, 
they are equipped with the necessary 
ROMs and are sold. 

Apple protested to both the 1TC and 
Customs. The ITC has power, under Sec¬ 
tion 337 of the Tariff Act of 1930, to issue 
an order (to be enforced at all ports of en¬ 
try by Customs) barring the import of 
goods involved in an“unfair act or prac¬ 
tice” in foreign trade. Customs has in¬ 
dependent power, under Section 602 of 
the Copyright Act, to bar entry of 
“piratical copies” of copyrighted works. 


microNEWS corn'd from page 

• outlines the overall strategy of these 
two major developers; 

• presents other product strategies 
where they enlarge upon and/or 
contribute to the company’s oper¬ 
ating system strategy; 

• discusses the recent spate of Unix- 
related announcements; and 

• examines up-and-comers such as 
AT&T, Softech Microsystems, and 
Pick. 

The report concentrates on detailing 
the current status, strategies, and future 
plans of the two market leaders and the 
leading contender. Some highlights 
follow: 

Digital Research. Digital’s identity is 
very much tied into being a partner in 
software solutions with both applications 
developers and end users. In all, the 
company has over 1000 OEM accounts 
(about 500 for all operating systems), 
and their products represent about 1.5 
million licensed users. 

Microsoft. Though the company is not 
subservient to IBM, it is undeniable that 
its association with the PC has been for¬ 
tunate. It has been estimated that about 
40 percent of all the personal computers 
shipped in 1983 were shipped with the 
Microsoft operating system. There are 
also estimates that MS-DOS “owns” 
about 90 percent of the 8088/8086-based 
operating systems market. 

Unix—AT&T Technologies. Unix, by 
far the most sophisticated of the oper¬ 
ating systems discussed, has had the 


The ITC concluded that supplying 
ROM-less microcomputers, which would 
later be combined with ROMs in the 
United States to complete the product and 
cause a copyright infringement, was “un¬ 
fair.” But Customs ruled that a piratical 
copy is a copy, not something that will be 
used with a copy, and it therefore declined 
to issue its own order barring entry of the 
“Apple clone” ROM-less microcom¬ 
puters. However, Customs will enforce 
the ITC’s order. 

Hearing record available 

The record of the Hearing on S.1201, 
the Semiconductor Chip Protection Act 
of 1983, before the Subcommittee on 
Patents, Copyrights, and Trademarks of 
the Senate Committee on the Judiciary 
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broadest migration of any portable 
operating system. Some estimates in¬ 
dicate that up to 70 hardware vendors 
have implemented some form of Unix. 
Approximately 60,000 source binary 
licenses have been signed, and about 
100,000 Unix machines are currently in¬ 
stalled. 


Apple Computer calls Macintosh a 

Apple Computer announced it has 
shipped more than 70,000 Macintosh 
computers since the product was in¬ 
troduced on January 24. The company 
originally projected that it would ship 
50,000 units within the first 100 days, 
which ended May 3, and reached that 
quantity in just 74 days. Apple expects to 
sell 250,000 Macintosh computers by 
September 28, the end of its 1984 fiscal 
year. 

The sales forecast was part of the cri¬ 
teria established by Apple to measure the 
success of the Macintosh computer dur¬ 
ing its first 100 days on the market. Ap¬ 
ple also predicted that the Macintosh 
would emerge as a milestone product 
among consumers, computer dealers, 
and independent software developers. 

“Apple set very aggressive goals, and 
we believe that we have exceeded those 
goals. Based on the response we’ve had 
so far, we feel that the Macintosh is on 
its way toward becoming the third in¬ 
dustry standard product in the personal 
computer business,” said Steven P. 
Jobs, chairman of the board at Apple. 
“We reached our 50,000 unit sales goal in 


(May 19, 1983), is now available. The 
168-page paperbound volume includes 
testimony and statements from Repre¬ 
sentative Don Edwards of California, 
Assistant Register of Copyrights for Legal 
Affairs Dorothy Schrader, Thomas 
Dunlap of Intel Corp., Dr. Christopher 
Layton of Intersil Inc., Harvard Law 
School Professor Arthur Miller, Jack Bid¬ 
dle of the Computer and Communica¬ 
tions Industry Association, Ronald Palen- 
ski of the Association of Data Processing 
Service Organizations, Patent Office of¬ 
ficials, and Leslie Vadasz, an IEEE Fellow 
and official of Intel Corp. IEEE Micro 
readers interested in receiving a com¬ 
plimentary copy can request it from 
Senator Charles Mathias, U.S Senate, 
Washington, D.C. 20510; enclosure of a 
self-addressed mailing label will facilitate 
response. 


Other companies briefly profiled in the 
report are Softech Microsystems Inc. and 
Pick Systems. 

The report is available through IDC’s 
Software and Services Information Pro¬ 
gram for $1800. For further information, 
contact Damian Rinaldi at (617) 
872-8200. 


success 

just 74 days. By comparison, it took two 
and a half years to sell 50,000 Apple IIs, 
and seven months to sell the same 
number of IBM PCs. Consumer demand 
for Macintosh during the first 100 days 
was at least double the 70,000 units that 
we could produce.” 

Response from independent devel¬ 
opers and authorized Apple dealers 
has been equally positive. Since the in¬ 
troduction of the Macintosh, Apple has 
received over 5,000 inquiries from in¬ 
dependent developers. More than 1000 
computers have been sold to these firms. 
Of the 150 software packages anticipated 
by the end of the year, 50 are expected to 
be available this summer. 

During Macintosh’s first 100 days, 
agreements were reached with three of 
the nation’s largest business-oriented 
retail chains to sell the computer, in¬ 
dicating significant acceptance of the 
Macintosh in the business market. Sears 
Business Systems Centers, Businessland 
Inc., and The Genra Group—who serve 
the office, professional, and business 
markets—all announced plans to carry 
both the Macintosh and Lisa. 
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microREVIEW 


by David L. Hannum 

AT&T Information Systems 
Room 59-3A37 
99 Jefferson Road 
Parsippany, NJ 07054 


We have heard much of portable com¬ 
puters in the past few years, and we have 
seen a trend begun by the Osborne I 
evolve into what is now a varied and 
stable market in its own right. Most of 
these “portables,” however—weighing 
in at 26-30 lbs. and packaged in 
somewhat unwieldly proportions—have 
earned the more appropriate moniker 
“transportable.” In other words, you 
have to think about it before you pick it 
up. You don’t want to move a transpor¬ 
table any more than you have to, and 
there are plenty of places you wouldn’t 
take it. 

Last year’s introduction of the 9-lb., 
battery-powered Gavilan computer 
changed all that. With its flip-top LCD 
screen and its built-in disk drive and 
printer, the Gavilan was a commuter’s 


dream. That is, until he saw the price tag: 
$4000 without the printer. 

Although its price banished it to the 
executive toy category, the Gavilan did 
redefine industry standards for the por¬ 
table micro. Since then, two entries into 
the “mini-portable” class by major 
manufacturers—Hewlett-Packard and 
Sharp Electronics—suggest that this 
trend, too, may catch on. HP’s new Por¬ 
table 110 is still expensive at $3000, but it 
may provide interesting material for a 
review at a later time. 

The Sharp PC-5000 

This month we’ll look at the PC-5000 
by Sharp, a mini-portable that does just 
about everything the Gavilan does for 
about half the price. 


The basic PC-5000 is a single unit with 
a standard QWERTY keyboard, eight 
function keys, and flip-top LCD screen 
with an eight-line by 80-character matrix. 
The heart of the computer is its 16-bit In¬ 
tel 8088 CPU, which uses the MS-DOS 
operating system. 

The PC-5000 is said to be compatible 
with the IBM PC, but because of the 
changes necessary to accommodate the 
smaller display and the fewer function 
keys (eight instead of 10), not one of my 
IBM PC programs would run on this 
unit. This may be overcome with a little 
creativity on the user’s part. It will prob¬ 
ably not pose a major problem anyway, 
since there’s already a substantial 
amount of software for the machine 
(more on this later). 

The PC-5000 is the only mini-portable 
which currently offers an optional 
printer that is internal to the unit (not a 
clip-on), and it is a very clever device in¬ 
deed. The virtually silent “thermal/ther¬ 
mal transfer” printer provides the user 
with a choice of printing methods: (1) 
thermal printing using heat-sensitive 
thermal paper, or (2) “thermal transfer” 
printing, which uses a disposable ribbon 
cartridge to produce near-letter-quality 
type on plain bond. 

Printing is not very fast (37 characters 
per second), and the type is fairly small. 
On the whole, though, I would say that 
its output is more than satisfactory for 
on-the-spot hard copy—and it does have 
graphics capabilities as well. 

The most interesting aspect of this 
machine may be its many methods of 
memory storage. Built into the box is 
128K of RAM (expandable to 256K) and 
192K of ROM. Internal floppy-disk 
drives are also available in either the 
514-inch or 3 Vi -inch formats, both with 
360K capacity. The disk drives are expen¬ 
sive, though: $995 for the 5!4-inch ver¬ 
sion and $699 for the 3 / 2 -inch. 


THE SHARP PC-5000 is a good representation of the new 
industry standard for truly portable microcomputers: small, 
light, battery-powered and fully equipped, this model is 
designed both for travel and for use in transit. The system 
currently comes bundled with the Sorcim family of software, 
and other popular software programs are available as well. 

Sharp has managed to incorporate not one but two methods 
of software storage into the PC-5000: internal floppy disc 
drives and the first standard use of bubble memory. The com¬ 
puter operates on a rechargeable lead battery, and with the 
optional internal printer and modem, it still weighs in at under 
13 lbs. 

Responding to a need by professionals for a complete take- 
anywhere, anytime system, Sharp seems to have filled the bill. 
Now if Sharp USA can support this product with the service 
and dealer support it deserves, it may get a foothold in the 
volatile personal computer market. 
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Bubble memory 


But the real star of the Sharp PC-5000 
is its bubble memory storage for soft¬ 
ware, which constitutes the first standard 
use of the bubble technology in a com¬ 
puter of this type. 

The machine comes standard with one 
128K bubble cartridge, but additional 
bubble units can be purchased for $269 
each. Although a limited amount of soft¬ 
ware is currently available on the bubble 
units, I am told that many dealers will 
download your favorite programs onto 
cartridges for no extra charge. 

The computer is powered by a re¬ 
chargeable lead battery which—accord¬ 
ing to the marketing rep I spoke with— 
provides for eight hours of constant use 
without the printer and 1 Vi to two hours 
of use with the printer in constant opera¬ 
tion. 

The unit still weighs in at only 10 lbs. 
unless you add the optional 300-baud 
modem, which brings it up to about 13 
lbs. 

Software for the PC-5000 

The system currently comes bundled 
with Sorcim Superwriter word process¬ 
ing; Superplanner, an executive planner/ 
calendar program; Supercalc; Super- 
comm, a communications package; and 
Supertools, a set of utilities integrated in¬ 
to the menu scheme that allows easy use 
of Dir, Copy, and other important func¬ 
tions. 

Also available are the popular Word¬ 
star, dBase II, PFS:File, PFS:Report, 
Easyplanner, Easywriter II, and Easy- 
comm. The marketing rep assures me 
that more are on the way. 

I had no trouble adapting to these pro¬ 
grams; in general, they performed every 
bit as well as they were supposed to. In 
fact, I was pleasantly surprised by an oc¬ 
casional bit of user-friendliness—such as 
the “autoboot” program, which brings 
up the menu screen and applies a few 
human-engineered touches to the 
PC-5000 software. 

Sharp has pulled off a neat trick in 
packing the latest “stable” technology 
into a machine this small at such a 
reasonable price. My only real complaint 
about the PC-5000 is the glare (and thus 
eventual eyestrain) produced by the LCD 
screen. Otherwise, Sharp’s competition 
may have a hard time keeping up with it. 
At $1995, this machine may just be a 
mini-portable “for the rest of us.” 


SYSTEM AT A GLANCE 


Sharp PC-5000 by Sharp Electronics Corporation 

100 Sharp Plaza 

Paramus, New Jersey 07652 

(201) 265-5600 

1-800-732-8321 

GENERAL 


Model 

Dimensions 

Weight 

Price 


PC-5000 

12-27/32 x 12 x 3-7/16 inches 
10 lbs. 

$1995 (basic unit with one bubble unit and no 
disk drives) 


HARDWARE 

Processor 
Word size 
Memory 

Floppy disks 

Display 

Interfaces 


Printer 

Keyboard 

Modem 

Power 


Intel 8088 
16 bits 

128K RAM, expandable to 256K 
128K bubble cartridges (optional) 

192K ROM 

5.25-inch disk drive, 360K bytes each (one or 
two; optional) 

LCD, eight lines x 90 columns 
Graphics: 640 x 80 dots 

RS-232C port (one) 

External bus port (one) 

Audio cassette port (one) 

RAM/ROM expansion slots (two) 

Built-in: thermal or ribbon (optional) 

37 characters per second, 80-character width, 
also prints graphics 

Standard, with eight function keys 

Optional, 300-baud, 103-compatible; can be used 
as a conference phone 

Internal rechargeable lead battery or recharger 
pack 


SOFTWARE 

Operating system 
Languages 
Word processor 
Data manager 
Spreadsheet 

Communications package 
Utilities 


MS-DOS 2.0 
Basic 

Superwriter 

Superplanner 

Supercalc^ 

Supercomm 

Supertools 



MANUALS AND TUTORIALS 


Keep those cards and letters coming. 
Your requests and comments are much 
appreciated, and I will try to respond to 
each of them as time permits. 


Manuals 


Provided for each software package. A user’s 
manual is provided with both the PC-5000 and 
each optional hardware unit. 
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microSTAND4RDS 


by Robert G. Stewart 

Stewart Research Enterprises 
1658 Belvoir Drive 
Los Altos, CA 94022 


Is Unix suited to be a standard for micros? 


Recently I’ve been using Unix III on a 
Motorola 68000/IEEE 696-based system 
to perform computer graphics analyses. 
And after reading AT&T’s ads suggesting 
that Unix is our prime candidate for a 
microcomputer operating system, I’d like 
to share with you a few conclusions based 
on my personal experience with it. 

Let me begin by noting that the first two 
letters of Unix are the same as the first two 
letters of “unfriendly.” The unnecessarily 
abstruse language comprising the com¬ 
mand structure seems intended primarily 
to reduce keystrokes, as if everyone were a 
one-finger hunt-and-peck typist. Next, 
one confronts a directory and file secrecy 
system clearly designed for a large com¬ 
puter installation rather than a single-user 
microcomputer. Multi-user operation 
with Unix is a real measure of the capa¬ 
bilities of a disk drive, since swapping to 
disk occurs frequently. If you have any¬ 
thing less than a high-performance hard¬ 
disk drive, the multi-user performance is 
totally inadequate. 

A true and utter disaster is the absence 
of a file back-up system for the editor, Vi. 
The user must devise his own backup 
methods to avoid calamity in case of a 
hardware crash. Still, even with this 
precaution, it is easy to lose all the 
backups if the hardware is at all flaky. 
Unix prefers to keep files in RAM, rather 
than writing them out to disk after an edit 
is exited. To avoid file loss, multiple 
“syncs” must be used before and after 
edit, load, and compile operations to 
force the operating system to write the 
files out to disk. 

In many applications, microprocessors 
must interface with hardware. This can re¬ 
quire fixing and accessing code in certain 
memory locations. A multi-user, mem¬ 
ory-mapped operating system objects to 
such usurpation of its prerogatives. Only a 
“superuser” has access to this privilege in 
Unix. This once again shows the multi¬ 
user limitations of Unix for applications 
involving direct hardware interfacing. 

Having used Gary Kildall’s CP/M 
operating system for eight years, I really 


appreciate finding space left in memory 
for my programs. Not only does Unix 
need about 15 times as much RAM as 
CP/M, it needs more than 10 megabytes 
of disk space to contain the system. So. . . 
is it worth it? In my opinion, for a single- 
user microcomputer system, probably 
not. The years of lily gilding which have 
gone into Unix are overkill for this type of 
application. 

Well then, what’s good about Unix? 
Clearly the massive documentation which 
is supplied or available is a real credit to 
Bell Labs’ determination to provide users 
and system maintainers with credible 
writeups of myriad details. The screen 
editor, Vi, is reasonably powerful and 
easy to use, with the exception of the 
backup faux pas mentioned above. The 
program fsck (file system check) allows 
salvaging munged disks. Shell script files 
and alias files help make Unix somewhat 
more user-friendly. 

The programming language C is overly 
compact and seems designed to minimize 
writing lots of comments. The reason is 
that the code is so dense, with several 


Dennis Blake 


It is with great sadness and regret that I 
inform you of the recent death of Dennis 
V. Blake, BSc, C Eng, FIEE. 

Dennis Blake was known to us all for 
his work in editing the P896 specification. 
He successfully created a great document 
from the sometimes haphazard and inade¬ 
quate inputs we provided to him. Dennis 
spent a great deal of his professional life 
working with the standards and frequent¬ 
ly represented the UK in international 
standards meetings. He was also instru¬ 
mental in obtaining funds from the UK 
Department of Industry to allow indi¬ 
viduals to participate fully in the develop¬ 
ment of the P896 standard. Dennis was 
the project officer appointed by the 


statements typically contained on one 
line, that comments are hard to include 
with the same density. In this sense C 
reminds me of Forth. Further, the sub¬ 
routine response to a calling program is 
different from what is expected by, say, 
Fortran. As a result, at least for Silicon 
Valley Software’s Fortran 77 compiler, 
“wrappers” are required to interface C 
and Fortran routines. Moreover, this 
compiler has no capability for bit manipu¬ 
lation in bytes and words—a severe hand¬ 
icap for hardware interfacing. Evidently, 
high-level-language compiler writers do 
not understand that systems that talk to 
hardware need direct bit-manipulation 
capability. 

To touch on yet another point, the 
hardware problems of megabyte memory 
cards made me a believer in the necessity 
of error correction, rather than simple er¬ 
ror detection, for large memory systems. 

Unix needs to be made simpler, safer, 
cheaper, faster, and more user-friendly. It 
also needs to provide better hardware in¬ 
terfacing and significantly expanded 
graphics capabilities. 


Department of Industry to oversee the use 
of these funds as well as chairman of the 
IEE’s Subcommittee on Computing Stan¬ 
dards—the parent body responsible for 
the IEE Working Party on Backplane 
Buses. 

Without Dennis’ considerable efforts 
and strong personal commitment to the 
working group, the P896 specification 
would not have been completed in the 
time it was. Indeed, it might not have been 
completed at all. 

I am sure I speak for all members of the 
working group when I say that Dennis will 
be sadly missed from our meetings. For 
many of us, Dennis’ departure means say¬ 
ing goodbye to a dear and valued friend. 


From Paul Borrill, chairman of the P896 working group 
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New Products Editor: Victor P. Nelson 


To obtain more information 
about a product or service 
featured in New Products, 
circle the appropriate number 
on the Reader Service Card at 
the back of the magazine. 


NEH/ PRODUCTS 


Minicomputer features fault management 


Logic simulation system 
offered for IBM PC/XT 

Logicpro, a software package that converts 
any IBM PC/XT into an engineering work¬ 
station for logic design, has been introduced 
by E/Z CAD. Designed for both board-level 
and integrated-circuit logic designers. Logic- 
pro offers an alternative to high-priced 
workstation packages. 

With capabilities comparable to mini and 
mainframe level industry standard simulators 
such as Tegas and Logis, E/Z CAD’s system 
fits application areas ranging from gate-arrays 
and custom and standard-cell users to system 
designers using 7400 or 4000 series logic 
families. 

Logicpro, semi-interactive professional 
logic simulation system, includes several 
packages. One is Waveform, a high-resolution 
graphics utility, that displays the timing 
diagrams generated by Logicpro in color. Also 
useable with Logicpro are the TTLLIB and 
CMOSLIB libraries, each containing over a 
hundred 7400 and 4000 series device models. 

Logicpro can simulate all standard logic 
elements, including three-state elements, 
n-and p-channel transistors, CMOS transfer 
gates, wired-or nodes and RAM and ROMs 
with its built in functional models. It can also 
perform fault-detection for stuck-at-one and 
stuck-at-zero nodes, automatic spike detec¬ 
tion and race analysis, realistic timing analysis 
with both rise and fall propagation delays and 
DC initialization analysis. 

Logicpro permits easy troubleshooting of 
designs with features such as user control of 
DC convergence algorithms, ability to output 
all or partial network states at any time step 
during simulation, and network listing and 
verification tables. 

Logicpro is available immediately in two 
versions: Logicpro/3000 with 3000 nodes 
capacity needs 320K system and is priced at 
$650. Logicpro/1000 with 1000 nodes capacity 
needs 256K system and is priced at $495. The 
Waveform utility, at $350, requires a color 
graphics board and monitor or shades-of- 
green as in COMPAQ. The TTLLIB and 
CMOSLIB at $150 each are part-number- 
based and pin-referenced for ease of use and 
are user expandable. The package comes with 
a complete manual including a tutorial and ex¬ 
amples. 
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The Parallel 300, a minicomputer that in¬ 
corporates fault tolerance, has been introduc¬ 
ed by Parallel Computers. 

The Parallel 300 is intended for use in opera¬ 
tional information-systems applications, 
those environments where computers are 
critical to the flow of products and services. 
Typical applications could include factory 
automation; office automation and engineer¬ 
ing workstation networks; communications 
industries; car-rental agencies, travel agents, 
hotels, and service businesses that use on-line 
computers; trucking, freight handling, and 
shipping; and medical clinical labs. 

Parallel 300 computer users need no train¬ 
ing or tools to restore the system to its fully 
operating state. All components can be remov¬ 
ed and replaced quickly without tools, usually 
within a few minutes. In the event of a compo¬ 
nent failure, the computer alerts the user to the 
exact nature of the problem and provides step- 
by-step instructions for replacing the faulty 
component. Parallel also maintains a 24-hour, 
seven-day-a-week hotline to assist users. 

The Parallel 300’s redundant architecture 
duplicates all vital components, including pro¬ 
cessors, disk drives, disk controllers, and 
power supplies. If any of these components 
fail, the computer protects itself from data 
loss, error, or shutdown, and continues to 
operate. 

A closely coupled pair of parallel¬ 
processing units, each using a Motorola 
MC68010 virtual-memory microprocessor, 
executes all tasks simultaneously. If one pro¬ 
cessor fails, the breakdown is detected by the 
Parallel 300’s synchronization logic. A self¬ 
diagnostic procedure identifies and isolates 
the faulty processor, and the remaining pro¬ 
cessor continues to run the application. 

Also duplicated are Winchester disk drives 
and disk controllers. All data are written onto 
both disks, and each disk is connected to a 
separate controller. If a controller fails, the 
system isolates it while the other continues 
alone until the component can be replaced. 
The redundant disk architecture also provides 
for motor malfunctions such as a read or write 
error stemming from a defect in the disk 
media. 

Parallel 300’s entire system runs directly off 
its batteries, which are kept charged by exter¬ 
nal power. The use of batteries effectively 


isolates the system from fluctuations in exter¬ 
nal voltage. In case of a total power failure, the 
batteries keep the system operating for up to 
15 minutes. An optional battery pack main¬ 
tains the system for up to 90 minutes. In the 
event of extended power loss, the system will 
shut itself down systematically while safeguar¬ 
ding data. When external power resumes, the 
system will automatically continue processing 
from the point it left off. 

The Parallel 300, Model 30 has a list price of 
$74,900. Volume discounts are offered to 
OEMs. Optional expansions to the basic 
system include additional memory, disk, com¬ 
munications, local area network, and soft¬ 
ware. 
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Three key support chips enhance microprocessor system 


Intel announced two new controller chips, 
the 8208 and 82062, and an improved version 
of another key microprocessor system support 
chip, the 8256AH. The company claims that 
these three products make it easier for engi¬ 
neers to design main memory, mass storage, 
and communications subsystems. Intel’s 8208 
high-speed dynamic RAM controller supports 
faster design of dynamic RAM memory by 
combining the control functions onto a single 
chip. The 8208 simplifies the dynamic memory 
interface and refresh requirements to permit 
designers to add larger amounts of dynamic 
RAM without trading off shorter design cycles 
and reliability. A single-chip controller, the 
82062, provides nearly all the logic needed to 
build a Winchester disk drive controller sub¬ 
system. 

The 8256 multifunction peripheral chip has 
been improved to offer higher speed and a 
lower cost plastic packaged part, the 8256AH. 
Reduced in area from 220 mils per side to 159 
mils per side, the 8256AH combines the func¬ 
tions of four individual chips to create a pro¬ 
grammable serial communications interface, 
parallel I/O ports, five programmable timer/- 
counters and an eight-level priority interrupt 
controller. 

The 8208 replaces up to 20 TTL chips or 9 
MSI chips. It provides all the signals needed to 
control 64- and 256-kilobit dynamic RAMs. 
This single VLSI chip directly addresses and 
drives up to 1M byte of memory without exter¬ 
nal drivers. Designed for the simplest interface 
to Intel’s 80186 and 80188 microprocessors, 
the 8208 can also be used with other micropro¬ 
cessors. 


The 82062 is designed for personal com¬ 
puter and office workstation designers whose 
systems will use the new 5 Vt -inch disk drives 
from manufacturers such as Seagate, Shugart, 
Tandon, and Computer Memories. 

The 82062 provides all the drive-control 
logic plus the control signals that simplify the 
design of external phase-locked loop and 
write-precompensation circuitry. Controlled 
by the system’s CPU using six commands, the 
82062’s current transfer rate is 5 megabits per 
second. Future versions will support the new 
10 megabits-per-second ST412HP and ESDI 
interfaces. Sector lengths can be programmed 
to be 128, 256, 512 or 1,024 bytes. 

By using six high-level commands—restore, 
seek, read sector, write sector, scan ID and 
write format—the CPU can control the in¬ 
itialized 82062 with single byte commands. In 
addition, the 82062 adds all the required track 
formatting to the data field, including 2 bytes 
of CRC code. 

Intel’s 8256AH multifunction peripheral 
chip combines four commonly used functions 
into a single 40-pin device. It supports serial 
communications, parallel input/output, tim¬ 
ing and event counting and priority interrupt 
control. All of these functions are fully pro¬ 
grammable, based on the contents loaded into 
its nine registers. In addition, the five timer/ 
counters and two parallel I/O ports may be ac¬ 
cessed directly by the microprocessor. 

This improved HMOS II version of the 
Siemens 8256A and the Intel 8256A has the 
same on-chip, baud-rate generator, a 1 mega- 
bit-per-second serial port, two 8-bit parallel 
I/O pots, five 8-bit programmable timer/ 


counters (four of which can be cascaded to 
create two 16-bit timer/counters) and an 
8-level interrupt controller. The new plastic 
packaged 8256AH is faster than the 8256A. 
The 8256AH replaces several lesser integrated 
components making the overall design smaller 
and more reliable. 
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Emulation tools run almost any 
CP/M-80 program on a PC 
without boards or hardware 

80Mate, a CP/M-80 emulator utility, and 
80Term, a terminal emulation program, are 
available from Vertex Systems. Most 
CP/M-80 programs can be run on PC/MS- 
DOS micros without the need for expensive 
coprocessor boards. CP/M-80 programs run 
with 80Mate use existing CP/M commands. 

80Mate uses ordinary PC/MS-DOS disks 
and devices. The unprotected CP/M-80 pro¬ 
gram is transferred to a DOS disk. 80Mate is 
run, and the CP/M-80 program is “booted” 
and operates as though on the computer it was 
written for. CP/M programs can be trans¬ 
ferred using conventional serial file methods. 
Vertex suggests using the Xeno-Copy Plus for¬ 
mat conversion utility when speed, accuracy, 
and convenience are required. Safe to use with 
hard disks, 80Mate is priced at $99.50. 

Vertex Systems fully supports end-users and 
dealers with technical help. 80Term, priced at 
$44.95, may be necessary for several selected 
programs to match the display characteristics 
to the new host computer. 
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Converter runs CP/M-86 
software on PC-DOS, MS-DOS 
operating systems 

The O.S. Converter from Dynamic Micro¬ 
processor Associates permits PC-DOS (MS- 
DOS) object code to run on CP/M-86 micro¬ 
computers and enables CP/M-86 object code 
to run on MS-DOS systems without loss of 
speed. The O.S. Converter permits users to 
run such programs as Basic, Fortran, Pascal, 
and other language compilers, as well as 
utilities like Assembler and Linker. 

The new program operates by loading a 
target program into memory and creating the 
environment that the program expects. There 
is no interpretation of instructions; the pro¬ 
gram itself remains in control of operations. 
The O.S. Converter is 4K bytes. When in use, 
it resides just above the operating system in 
RAM and enables the program being run to 
take full advantage of available memory. The 
O.S. Converter for the IBM PC is supplied 
with a companion program that enables PC- 
DOS systems to read CP/M-86 files. 

The O.S. Converter for use with either PC- 
DOS (MS-DOS) or CP/M-86 is available now 
for $115. 
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Intel’s 82062 Winchester disk controller. 
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UNIX port to IBM PC/XT available 

International Data Services, a UNIX sys¬ 
tems and software supplier, is offering a 
UNIX port to the IBM PC/XT. The product, 
UnX-II, is an implemenation of AT&T 
Technology’s UNIX System III with Berkeley 
4.1 enhancements. UnX-III adheres to the 
standards of the AT&T version while offering 
the performance enhancements of 4.1 BSD. 

UnX-II is a full implementation of UNIX 
System III, making available to the user of the 


For Z-80 CP/M 2.x users, MicroMotion is 
offering Masterforth, the complete profes¬ 
sional programming language that includes a 
built-in macro-assembler with local labels, a 
screen editor, and a string handling package. 

The input and output streams are fully 
redirectable and use the host operating file 
structure. Also available for Apple II/II + / 
lie users, Masterforth features a floating 
point option. 

The package includes Forth Tools, a 
200-page textbook, a technical reference 


IBM PC/XT the powerful UNIX functions 
found on minicomputers. Among these 
features are multitasking and dual-user 
capabilities. In a two-user system, the PCs or 
XTs may be connected via a sync port directly 
saving the expense of a local area network. 

UnX-II will be offered in both a cost- 
effective, bundled package as well as in an un¬ 
bundled form, allowing users a choice of pric¬ 
ing and application. The basic product, which 


manual, and a complete listing of the Master¬ 
forth nucleus. Forth Tools gives the user an 
in-depth view of input and output, from 
reading the input stream to writing a mailing 
list program. Numerous examples are also 
provided. 

Masterforth retails for $100, and with 
floating point for $140. 
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retails for $595, includes the system III Kernel, 
basic (Bourne) shell, utilities, and uucp. 

Among the optional utilities are the 
Berkeley 4.1 enhancements, including the VI 
editor and C shell, at $150. A PC DOS shell, 
which allows a non-UNIX-familiar user to 
make full use of the system via PC DOS com¬ 
mands, is available for $150. SCCS is available 
for $ 100. These options may be purchased as a 
package for $395. The UnX-II port plus all op¬ 
tions are available in a bundled package for 
$895. Distributor discounts are available. IDS 
offers the Writers Workbench at $995. 

The IBM PC/XT hardware requirements 
for full use of the port include a minimum of 
320K byte memory and the optional installa¬ 
tion of the Intel 8087 math processor for 
enhanced performance. All of the standard 
UNIX system calls are supported. A manual is 
available from IDS for $25 that describes 
system functions and operation. 
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Masterforth available for Z-80 CP/M 2.x users 


Speech recognition equipment operates over standard telephone lines 


Votan now has available the VPC 2000 
Voice Card, which provides voice recognition, 
speech generation, and telephone manage¬ 
ment capabilities in one package. With Voice 
Key software, the Voice Card can be used im¬ 
mediately for speech command and program 
control. 

Votan has also introduced the VTR 6000 
Voice Terminal. Connecting to any computer 
supporting an RS-232 serial port and xon/xoff 
protocol, the Voice Terminal can connect in¬ 
directly to the host, or be connected between a 
CRT terminal and a host to supplement key¬ 
board/screen transactions. Voice Key soft¬ 
ware permits immediate speech command and 
control of the computer. 

Voice Key software incorporates voice 
capabilities into existing software packages 
without any modifications to the application 
software itself. For each application program, 
the user may define up to 64 voice utterances 
that are linked to sequences of key strokes, up 
to 30 characters each. At runtime, the Voice 
Card listens for voice commands from the 
user, automatically typing the key strokes 
linked to each command when it is uttered. 
The keyboard remains active and can also be 
used in a normal fashion. For each utterance, 
the user may choose whether or not to hear 
voice response messages to confirm the voice 
command. 

Voice Key at runtime, for the Voice Ter¬ 
minal, listens for voice commands from the 
user, automatically typing the key strokes 
linked to each command when it is uttered. For 
example the spoken word “initialize” might 
be used to set up normal parameters on a word 
processing program, such as to set the right 
margin, double space, turn off justify and 
hyphenate options, and eliminate the help 
menu. 

The Voice Card features continuous 
speaker dependent recognition, which allows 


an individual to speak to the computer in a 
normal conversational flow. A word spotting 
capability will pick out target words located 
anywhere within a stream of normal conversa¬ 
tion. 

Voice Card operates over standard tele¬ 
phone lines. Two-way communication with a 
PC from remote locations is possible. Voice 
Card provides complete telephone interfacing 
capabilities including auto answer, auto dial, 
and touch tone encoding and decoding. A 
software program, the Telephone Manager, is 
provided to give users immediate access to 
these hardware facilities. It provides a voice- 


controlled telephone dialer and a sophisticated 
automatic answering/voice mail system. 

The VPC 2000 is composed of a printed cir¬ 
cuit board that plugs into any of the long aux¬ 
iliary system bus slots on the IBM PC. 
Microphone, speaker, and complete software 
and documentation are included in the $2,450 
price. 

The VTR 6000 is a stand-alone voice I/O 
subsystem with its own chassis, power supply, 
microphone, and speaker. Complete software 
and documentation are included in the $3,950 
list price. 
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Designer pop-up menu software and upgraded optical mouse are available 



Mouse Systems has announced Designer 
Pop-up menu software and its second genera¬ 
tion optical mouse family. 

The new software allows personal computer 
users to design or personalize pop-up menus 
for most IBM PC and PC-compatible soft¬ 
ware. Pop-up menus eliminate the need to 
memorize and type complex commands. Users 
simply select a command from the pop-up 
menu by pointing at it with PC Mouse and 
pressing one of its three buttons. 

Designer Pop-up menus work on the IBM 
PC, IBM PC-XT, PCjr, and PC-compatibles 
and require no modifications to existing soft¬ 
ware. Users can design or personalize their 
own pop-up menus with any word processor 
that creates ASCII text files and a compiler 
provided by Mouse Systems. 

Unlike fixed menus, pop-up menus used 
with the PC Mouse appear on the screen only 
when needed and disappear when the desired 
command is selected. The pop-up menus are 
completely transparent to the underlying pro¬ 
gram and take up no screen space except when 
they are actually being used. 

For $20 Mouse Systems offers an upgrade to 
Version 3.00 to current pop-up menu users. 
The latest version includes pre-configured 
pop-up menus for Lotus 1-2-3, VisiCalc, 
Multiplan, Personal Editor, Volkswriter, 
WordStar, SuperCalc3, PFS:WRITE, and 
Multimate. Version 3.00 also works with 
Microsoft Word, the Multi-Tool series, and 
Window Manager when available. 

The list price of Designer Pop-up menu soft¬ 
ware, Version 3.00, is $95. 

Second Generation Mice 

Mouse Systems’ second generation of op¬ 
tical mice, designated M-2, does not require 
calibration and includes PC Mouse, Field- 
Mouse, and the basic M-2 Mouse. Other op¬ 


tical mice require calibration each time they 
are connected to power; this involves moving 
the mouse in large circles on the pad for several 
seconds. 

PC Mouse is an M-2 optical mouse that in¬ 
cludes Deisgner Pop-up menu software. PC 
Mouse connects to the IBM PC, IBM PC-XT, 
PCjr, and PC-compatibles through a standard 
RS-232C serial interface. Software installa¬ 
tion is a one-time, one-line procedure that re¬ 
quires no modifications to existing application 
software. 


FieldMouse is an M-2 optical mouse for use 
with non-IBM computers. It is similar to the 
PC Mouse, but does not contain pop-up menu 
software. The basic M-2 optical mouse is 
available in a variety of protocols and colors to 
meet the special requirements of OEM cus¬ 
tomers. 

PC Mouse is compatible with PC-DOS Ver¬ 
sions 1.10and2.00. It also works with Visi On, 
DesQ, Halo, CADPLAN and Auto CAD. 
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Data sentry modem prevents data theft 


Data Sentry, an intelligent modem from 
Lockheed-Georgia, can prevent data theft and 
other security breaches of personal, mini- and 
mainframe computer systems without requir¬ 
ing encryptions or changes in systems pro¬ 
gramming. 

Data Sentry uses a sophisticated call-up, 
call-back, and password sequence to thwart 
data thieves. It also offers all the telecom¬ 
munications features of conventional non- 
secure intelligent modems. 

An optional companion device, Remote-on, 
can turn a computer’s power on and off from a 
remote terminal once security has been 
cleared. 

Data Sentry’s security routine requests the 
phone number of someone wanting access to 
its computer. Then it hangs up and looks 
through its list of authorized numbers. If the 
caller’s number is authorized, Data Sentry 
dials the caller back and requests a password. 
The caller has three tries to give the right 
password. Without it, Data Sentry won’t 
return further calls from that phone number. 
Data Sentry also creates an audit trail of user 


passwords and phone numbers, whether calls 
are successful or not. 

A lower security mode, ideal for traveling 
business people, allows users to program Data 
Sentry to call back any number from which it 
gets the correct password. This mode is 
suitable for doctors, lawyers, and sales 
representatives who want access to the com¬ 
puter during non-business hours. 

With Remote-on, Data Sentry turns the 
computer on and off. For less restricted but 



still secure protection, Data Sentry will allow 
access to the computer system upon entry of 
only the correct password. 

In a nonsecure mode Data Sentry operates 
as a conventional intelligent modem. It 
features 300 or 1200 baud, full duplex, asyn¬ 
chronous operations with auto dial, auto 
answer, auto speed, and auto party selection. 

Six programmable directories are available 
for security and convenience. These range 
from ten 32-character “not allowed” phone 
numbers that Data Sentry won’t call back 
when it’s in a security mode. 

Terminal interface is a standard RS-232C 
cable. The telephone interface is a single 
telephone number drop with an RJ-11C con¬ 
nection. A battery backup protects menus and 
tables in memory during moves and power 
failures. A forced answer/originate feature is 
available for use with leased lines. 

List price of the Data Sentry is expected to 
be $895, while the Remote-on option lists for 
$145. 
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ICs combine low power consumption, high performance in data 
acquisition subsystems 


Two 8-bit, serial-output, A/D peripheral 
integrated circuits that combine low power re¬ 
quirements with fast conversion times are now 
available from Texas Instruments. The 
TLC540 and TLC541 can perform analog-to- 
digital conversions in 10 microseconds and 19 
microseconds, respectively. Including micro¬ 
processor access, this translates to taking a 
sample and performing an 8-bit ratiometric 
A/D conversion up to 71,000 times per se¬ 
cond (TLC540) or 28,000 times per second 
(TLC541). Each product dissipates 6.5 mW. 

The TLC540 and TLC541 can be used as 
complete data-acquisition subsystems pro¬ 
viding measurement data to a microprocessor 
via a serial data port. Possible applications in¬ 
clude test equipment, automotive instrumen¬ 
tation, industrial controls, robotics, toys, 
home computers, environmental controls, 
and some signal-processing applications. 

As serial-output data-acquisition ICs, the 
TLC540 and TLC541 perform a variety of 
functions needed to interface analog inputs to 
microprocessor systems. On-chip features in¬ 
clude an 8-bit, successive-approximation A/D 
converter, a 12-channel multiplexer, 11 analog 
inputs, sample-and-hold circuitry, three data 
registers, and microprocessor-control logic in¬ 
terfacing with an on-chip, three-line, TTL- 
compatible serial I/O port. 

The chips provide a built-in self-test mode 
and the capability for simultaneous read/ 


write operation. Separate system and I/O 
clocks allow broad control flexibility. 

In addition, the sample-and-hold circuitry 
is software programmable. By allowing 
designers to control precisely when the chip 
takes its sample, the TLC540 and TLC541 can 
be used as highly accurate sampling devices. 
The TLC540 has a 4-MHz system clock and a 
2-MHz data clock (maximum); the TLC541 
has a 2-MHz system clock and a 0.5-MHz 
data clock (maximum). The chips are accurate 
to + / - Vi least significant bit (LSB) over the 
entire temperature range. 


The POPCOM Model X100, a modem for 
users of personal computers and microcom¬ 
puters, is available from Prentice Corpora¬ 
tion. 

The Model X100 is capable of true voice 
and data switching at the user’s workstation, 
eliminating the need for separate lines for the 
telephone and personal computer. Dialing 
multiple calls to switch between voice and 
data is also eliminated. The voice and data 
handling feature also includes complete call 
progress monitoring and detection for dial 
tones, busy signals, remote ringing, voice. 


The TLC540 and TLC541 are pin-for-pin 
compatible with the MC145040, but offer 
conversion speeds 3X and 2X faster, respec¬ 
tively. The two parts are available in military 
(- 55 to 125°C) and industrial (-40 to 85°C) 
temperature ranges. A single 5-V supply is re¬ 
quired. 

Available now in 20-pin dual-in-line 
packages, the 100-piece prices of TLC540 for 
industrial and military uses are $3.60 and 
$7.34, respectively, the 100-piece prices of the 
TLC540 for industrial and military uses are 
$3.60 and $7.34, respectively. TCL541 is pric¬ 
ed at $2.74 and $5.00, respectively, for in¬ 
dustrial and military orders in 100-piece 
orders. 


data, and even line current disconnect. Fully 
compatible with 103, 113, and 212A dial-up 
modems, the Model X100 connects to all stan¬ 
dard single and multiline phone equipment. 

POPCOM can be installed on the wall, 
desk, or floor. It is adjustment-free in opera¬ 
tion (no switches or indicators) and provides 
answering for all voice and data calls, com¬ 
patibility with currently available communica¬ 
tions software packages, and the ability to 
adapt to a variety of RS-232 interface cables. 

The Model XI00 costs $475. 
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Modem capable of voice and data switching 



quirements of a specific application. The LMI 
Lambda also features an integral Multibus, 
which allows system engineers a wide choice of 
lower-cost third party peripherals for con¬ 
figuring the system and an optional Ethernet- 
II interface for communication with other 
computers. 
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Artificial intelligence computer introduced for office application 


Lisp Machine Inc. has introduced the 
Lambda/S, a compact, lower-priced version 
of its Lambda, an advanced LISP-based com¬ 
puter intended for artificial intelligence 
research and applications. 

Equipped with the same 32-bit LISP pro¬ 
cessor as the full-sized Lambda, the Lamb¬ 
da/S proves similar computing power in a 
smaller package. It is supplied with a 
169-megabyte Winchester disk drive and a 
12-slot card cage. 

The Lambda/S can be used as a stand-alone 
machine, and can also serve as a workstation 
on a local area network using a rack-mount 
Lambda or other host computer as a file- 
server. LISP software supplied with the 
machine can confer LISP-like file attributes 
on non-LISP file-servers. The Lambda/S is 
priced at $66,500. 

With the introduction of the Lambda/S, 
LMI offers its LISP machines in three basic 
configurations. In addition to the compact 
Lambda/S, the firm’s 32-bit LISP processor, 
which furnishes a 128M byte virtual address 
space, is available in a full-size rack configura¬ 
tion with either a 169M byte Winchester disk, 
priced at $69,900, or a 470M byte Winchester 
disk, priced at $76,500. The rack configura¬ 
tion of the Lambda offers a 21 -slot card cage. 
An optional 68010-based UNIX processor is 
available. 

The Lambda can be configured with LISP 
and 68010-based UNIX coprocessors in a 
high-speed, multiprocessor bus. This con¬ 
figuration enables the two processors to ex¬ 
ecute concurrently, communicating with each 


other through LMI’s extended STREAMS in¬ 
terface. A dual-processor Lambda offers users 
the ability to add intelligence to an existing 
traditional software package operating in 
UNIX by placing it under the supervision of an 
evolving LISP program. 

Lambda’s virtual control store with micro¬ 
compiler allows the machine’s architecture to 
be rapidly and easily conformed to the re¬ 
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CAE tool simplifies simulation tasks for engineers 


The MegaLogician Physical Modeling Ex¬ 
tension, a CAE tool that performs simulation 
modeling of complex logic blocks, has been in¬ 
troduced by Daisy Systems. 

PMX is a system design tool that integrates 
physical hardware subsystems and complex 
VLSI components, including complex VLSI 
microprocessors. When the component is 
plugged into a socket, the simulation informa¬ 
tion is directly acquired by extracting the 
behavior from the physical device itself. This 
virtually eliminates the breadboarding step 
previously necessary when complex compon¬ 
ents were utilized in a design. 


PMX is an option to the MegaLogician, a 
CAE workstation with a simulation capacity 
of one million gates and a performance level of 
100,000 evaluations per second. PMX sup¬ 
ports all commercial VLSI components, cus¬ 
tomer-designed PC boards and proprietary 
semicustom and full custom logic. Included in 


the commercial component category are the 
microprocessors and peripheral component 
families of Intel, Motorola, National, AMD, 
and Texas Instruments. 

PMX is priced from $15,000. 

Reader Service Number 14 


Simulation language designed for IBM PC 

A software package that can be used to mentation of GPSS 
simulate complex business and engineering 
systems, GPSS/PC, has been introduced by 
Minuteman Software. GPSS/PC is an imple- 


the General Purpose 
Simulation System language. 

GPSS/PC will be available for the IBM PC 
in May at a one-time license fee of $900. 

Reader Service Number 15 


Solid modeling is transferable from IBM PC to videotape 


Cubicomp has introduced an add-on circuit 
board to allow videotaping of images created 
with the company’s CS-5 solid modeling 
design system for the IBM PC. The new pro¬ 
duct, Video-5, increases the way solid model¬ 
ing on microcomputers can be used in anima¬ 
tion, advertising, engineering, architecture, 
CAD, and education. 

Video-5 synchronizes the display generator 
of the Cubicomp CS-5 system with an external 


video signal so that, with the addition of a sync 
generator and color encoder, high quality im¬ 
ages can be recorded in all standard video for¬ 
mats. CS-5 works with an IBM PC to allow 
users to create, display, manipulate, and store 
three-dimensional, full-color, shaded-surface 
solid models. 

CS-5 allows up to 4096 colors to be used 
simultaneously to color and shade the surfaces 
of images so they have realistic depth and tex¬ 


ture. Users can also create videotapes for use 
as portable demonstration tools. Tapes show¬ 
ing images in the progressive stages of design 
can be produced quickly. 

Video-5 allows users to record images in 
either NTSC or PAL standard video formats. 
Images can be recorded on all videotape for¬ 
mats, including VHS and Beta home video¬ 
tape as well as Umatic and Type C professional 
tape. 

Video-5 is factory-installed in the display 
generating hardware of the CS-5 system. Its 
role is to link the display generator and the 
video recorder to a color encoder and color 
sync generator, two other standard pieces of 
equipment required to videotape computer 
graphics images. In essence, Video-5 locks the 
timing of the signal transmitted from the 
display generating hardware so that it can be 
properly received by the video recorder. 

Priced at $900, Video-5 is available through 
Cubicomp. The CS-5 solid modeling system, 
consisting of display generating hardware and 
solid modeling software, is priced at $9,700. 

Reader Service Number 16 


New A/D converters feature low 
power consumption 

Motorola announces availability of the 
MC145040/MC145041 analog-to-digital con¬ 
verters with serial interface. These 8-bit 
devices are compatible with SPI, Microwire, 
and similar interfaces. 

The MC145040 features the following: 
operating supply voltage range of 4V to 6V for 
operation in NMOS as well as CMOS systems; 
operating temperature range of -55°C to 
+ 125°C; and conversion rate of 16 micro¬ 
seconds for the standard part. The MC145041 
also offers an on-chip oscillator that allows in¬ 
tegration with low-cost MCUs that do not out¬ 
put a clock signal. The inputs are TTL- 
compatible and can be driven with CMSO 
parts as well. The 20-pin DIP packages pro¬ 
vide for 11 analog channels. These devices will 
also be offered in plastic quad packages. 
Priced in 100-up quantities, the MC145040 is 
$2.89, and the MC145041 is $2.99. 

Reader Service Number 17 
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IEEE MICRO’S 
PRODUCT SUMMARY 

Product Summary Editor: Victor P. Nelson 


The Product Summary is a review 
of selected product announce¬ 
ments received at IEEE Micro’s 
offices during the last two 
months. For information on any 
of these products, circle the 
appropriate Reader Service 
Number on the card at the back 
of the magazine. 


MANUFACTURER R.S. 

& MODEL FUNCTION COMMENTS NO. 


Hewlett-Packard, 

ThinkJet 

Printer 

Ink-Jet printer interfaces with HP 150 (as well as IBM, Apple, 
and Compaq micros), operating at 150 cps. Combines print- 
head and ink reservoir in a single disposable unit with an 
average life of 500 pages. $495. 

Digital Microsystems, 

Hinet PC Adapter 

LAN 

adapter 

One-slot board adds 64K RAM, aZ-80 processor, and an 
RS-232 port to the IBM PC, permitting compatibility with 
Hinet members using either CP/M, CP/M-86, or MS-DOS. 

$495. 

Litton Systems, 

RS-232 Trackball 

Interface 

RS-232 

adapter 

Permits compatibility with any device that has an RS-232 
dataport (such as medical electronics components, training 
simulators, or arcade game devices). Self-contained within 
the TBSII package, unit eliminates the need for interface 
logic between trackball and computer. Price not stated. 

RAD Computers, 

MME 

Modem 

eliminator 

Replaces two synchronous modems normally required to 
direct-connect two microcomputers. Unit requires no AC 
supply connection and operates at all standard rates from 
1200 to 19,200 bps, with a range of 100 meters at 9600 bps. 
$150. 

Interphase, 

ESDI 3191 

Disk 

controller 

Device supports Enhanced Small Device Interface (ESDI) for 
5V4-inch Winchester disks. Compatible with all microcom¬ 
puters based on the Intel multibus, the unit features trimode 
operations (buffered, direct, cached), disk data rates to 20 
Mb/s, and self-diagnostic reporting. Single unit, $2250; under 
$1000 in quantity. 

PC Technologies, 

Xtender 

Cluster 

controller 

Upgrades PC-XT (or IBM PC with hard disk) to serve as host 
for up to five independent terminals, creating a clustered 
processing environment. Offered with 512K or 1024K bytes 
of memory, board operates with a wide variety of ASCII ter¬ 
minals at speeds to 19,200 bps. Price not stated. 

Eventide, 

WKBP-16 

Memory 

board 

Device requires no interface to fit Hewlett-Packard 9816, 
9826, and 9836 computers. Memory quadruples density, 
giving the 9816 its first megabyte of RAM without using an 
expansion interface. Price not stated. 

Intercontinental 

Micro, 

CPZ-4800X 

S-100 bus 

SBC 

Board supervises up to 16 slave processors and 4000 users 
in an Intercontinental ARC-100 network. Operating at clock 
rates of 4 MHz or 6 MHz, the unit’s memory management 
and direct memory access provide data transfer rates 300 
percent faster than Z-80 I/O block move rates. Including 
RS-232 communications and floppy controller personality 
boards, $982. 
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FUNCTION 


COMMENTS 


MANUFACTURER 
& MODEL 


R.S. 

NO. 


Qua Tech, 

8-bit and 12-bit 
A/D Systems 


Qua Tech, 
IEEE 488 GPIB 


Intel, 

iSBC 186/03, 
186/78 and 86/35 


Cado Systems, 
Tiger ATS 16 


A/D 

converter 

boards 


Multifunction 
board for IBM 


Single-board 

computers 


Host 

microcomputer 


Up to three modularized converters work in conjunction with 33 
a parallel expansion board to provide custom configurations 
to the user. Package includes Labstar software, which con¬ 
tains drivers for each module. Applications can be written in 
Basic or other assembly languages. 8-bit A/D system, $390' 

12-bit A/D system, $690. 

Board allows the IBM PC to emulate GPIB system controller, 34 
connecting up to 15 other talking, listening, or controlling 
devices for each module. Features programmable interval 
times and a parallel port that accepts modules such as A/D 
and D/A converters, reed relay and stepper motor controller. 

GPIB controller, $395; software support, $100; modules from 
$75 to $495. 

Based on Intel iAPX 186 and 86, computers provide com- 35 

plete system capabilities: CPU, operating system functions, 
peripheral interfaces, memory, and software. Company says 
new 6 3 /4-inch boards replace several conventional boards 
and are cheaper, faster, and consume less power. All func¬ 
tion under Intel’s iRMX 86 operating system. iSBC 186, 

$1650; 186/78, $3000 (engineering samples); 86/35, $3495. 

Built around the Intel 80186, system supports as many as 16 36 

terminals, printers, peripherals, or communications devices. 

With 512K RAM, a 10-Mb hard disk, and 1.2 Mb of diskette 
storage, the ATS 16 can simultaneously run accounting, 
word processing, financial planning, and message¬ 
processing applications. $12,895. 


Romar Computer 
Systems, 

Romar MX 


Apple-compatible Unit features both Apple DOS and CP/M operating systems, 37 

microcomputer a 6502-based CPU with ROM expandable to 192K, two slim¬ 

line floppies, a Z-80 card, and eight expansion slots. 

Detachable keyboard has 87 keys, including numeric pad 
and function keys. $695. 


Scientific Micro Systems, DEC- 

SMS 1000 Model 40 compatible 

system 


Available in several configurations, all of which run applica- 38 
tion software for DEC LSI-11/23 or LSI-11/73 CPUs without 
modification. Comes in upright floor model or rack- 
mountable package with one or two 5V4-inch Winchesters 
(12 to 70 Mb each). Choice of one 8-inch floppy or two 
5 Vi-inch, double-sided, RX50-compatible disk drives. Add-on 
cartridge tape subsystem is also available. From $5800. 


Materials Development 
Corporation, 

RM-1600 

IBM PC-compatible 
microcomputer 

System mounts in standard 19-inch racks and features 

9-inch screen, four expansion slots, and two IBM PC stan¬ 
dard disk drives. Built-in graphics capability has a resolution 
of 640 x 325, over 50 percent higher than IBM’s. $3995; with 
one floppy disk and one 10-Mb hard disk, $6495. 

Wyse Technology, 

WY-50 with WyseWord 

Dedicated 
word processing 
workstation 

System integrates a firmware version of Wordstar with a 
14-inch, nonglare green screen that tilts and rotates. 
Features user-selectable 80/132 column width and 32 
preprogrammed functions on 16 keys. $795. 

Microsoft, 

Microsoft Project 

Project 

management 

package 

Spreadsheet-style scheduler for the IBM PC provides in¬ 
dividual resource and cost tables, graphic displays of 
schedules and resource utilization, and extensive reporting 
capability. Program offers instant “what-if” feature; built-in 
facility generates and prints predefined reports for analysis 
or presentation. For IBM and “strict” compatibles only; re¬ 
quires 128K and one DSDD drive. $250. 


For more information, circle the appropriate RS No. on the Reader Service Card at the back ot the magazine. 
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MANUFACTURER 
& MODEL 


FUNCTION 


COMMENTS 


R.S. 

NO. 


Micropro, Lap computer 

Portable Wordstar, programs 

Calc, and Scheduler 


Designed for the Epson PX-8, programs have both user file 42 

compatibility with their parent versions and are available in 
English, French, and German. Portable Wordstar retains 
most features of its namesake. Portable Calc permits in¬ 
dependent setting of global, column, and cell formats, and 
variable column widths. Portable Scheduler combines the 
functions of an appointment book and travel alarm clock, 
storing many appointments at half-hour intervals. Price not 
stated. 


Computer Colorworks, Easy color 

Flying Colors graphics 


Designed for use with Commodore 64 and a standard 43 

joystick, package features paint capabilities, thick/thin lines, 
and various sizes of automatic circles and boxes. Drawing 
speed is adjustable, and a grid feature permits easy align¬ 
ment of figures. Pictures can be stored on disk and con¬ 
verted to slides. Also available for the Apple lie and II + . 

$39.95. 


Lytron Systems, 
LOIS 


Umbrella 
environment 
for software 


Lytron Systems, Office 

Office Organizer Tools application 

software 


Radio Shack, Fortran 

RM/Fortran 77 compiler 


Package lets users integrate their favorite off-the-shelf soft- 44 
ware into a seamless, menu-driven shell environment allow¬ 
ing data transfer between applications on networks or 
through links to mainframes. LOIS supports Microsoft’s an¬ 
nounced windowing software, and versions are available on 
MS-DOS and PC-DOS. Introductory price, $295. 

Tools can operate as stand-alone applications or as com- 45 

ponents of LOIS. Scratchpad ($60) creates, distributes, and 
files notes and memoranda; Calendar ($135) schedules ap¬ 
pointments and organizes memos; File Cabinet ($100) files 
and retrieves information in a variety of user-friendly 
methods; Calculator ($75) performs/displays manual or pro¬ 
grammable calculations and supports scientific notation, 
memory manipulation, and scientific and financial modes. 

Total package, $495. 

Allows users to write and execute mainframe-level Fortran 46 

applications on the TRS-80 Model 16B microcomputer. In¬ 
corporates popular extensions such as Hollerith and 
dexadecimal constants, an “include” statement, and sym¬ 
bols of up to 31 characters. $699. 


Supersoft, 
Diagnostics II 


Software Now available for MS-DOS and PC-DOS, package checks all 47 

maintenance components of computer systems to verify correct opera- 

program tion. Comes as a stand-alone program for end users or as a 

customized package for OEMs. Tests five main areas of 
computer’s system (CPU, memory, disk drives, terminal, and 
printer), isolating problems to the chip level. Price not 
stated. 


Ashton-Tate, 

Framework 


Quickview, 

Viewdex 


Integrated 

Software 


“Index card” 
filing system 


Package combines word processing, spreadsheet, business 48 
graphics, data management, forms processing, and “outline 
operator" in a window-like environment. Compatible with 
dBase II, also provides access to Lotus 1-2-3 and other ASCII 
files. Runs PC-DOS software through a DOS access facility. 

$695. 

Filing system for names, addresses, and phone 49 

numbers runs on Epson HX-20. Will also be intro¬ 
duced for NEC 8200 and Radio Shack TRS-80 Model 
100. Features pop-up menus for beginning users; 
provides search, edit, and omit commands. Price 
not stated. 


For more information, circle the appropriate RS No. on the Reader Service Card at the back of the magazine. 
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ACCESS 

recent books and articles 
on microcomputing 

by Peter R. Rony 

Dept, of Chemical Engineering 

Virginia Polytechnic Institute 
and State University 

Blacksburg, VA 24061 



Articles 

Business Computer Systems 

Vol. 2, No. 11, Dec. 1983: 

H. Swartz, “Parents Should Be Good Medicine 
for Software,” pp. 29-30. 

E. Horwitt, “Bringing Order to Project Jum¬ 
ble,” pp. 60-71. 

E. Benoit, “Business Takes Another Look at 
Lisa,” pp. 74-80. 

A. E. Smith, “Electronic Mail Goes First 
Class,” pp. 84-91. 

E. Horwitt, “More Bytes for the Buck,” pp. 
111-128 [Note: Includes table of Winchester 
disk drives]. 

D. Pryor and A. Smith, “Power Line Protec¬ 
tion,” pp. 131-41 [Note: Includes extensive 
buyer’s guide to power line protection]. 

J. Schlosser, “TKISolver Offers Solutions to 
Complex Business Problems,” pp. 151-157. 


Vol. 3, No. 1, Jan. 1984: 

H. Swartz, “A Watershed Case for 
Copyright,” pp. 25-26. 

E. Ferrarini, “Using Data Bases to Search for 
Software,” pp. 35-39. 

T. Johnson, “The Year Ahead,” pp. 42-73 
[Note: Opinions of experts, users, and dealers 
on trends, coups, products, and so forth]. 

E. Benoit, “Annual Report: Floppy Disk 
Drives,” pp. 111-121 [Note: Includes extensive 
table of floppy disk drives]. 

Byte 

Vol. 9, No. 1, Jan. 1984: 

B. Robertson, “California Hardware,” pp. 
52-54. 

Special section—“1984 and Beyond.” Articles 
include “Reason and the Software Bus,” “A 


General-Purpose Robot-Control Language,” 
“1984, the Year of the 32-Bit Microprocessor,” 
“Memory Cards: A New Concept in Personal 
Computing,” “Computer-Aided Design” 
[Note: Includes comparison of primitive 
features of CAD packages and a glossary of 
CAD terms], “Speech Recognition: An Idea 
Whose Time Is Coming,” “Using Natural- 
Language Systems on Personal Computers,” 
“Portables—1984 and Beyond: Idea- 
Processing Software and Portable Com¬ 
puters,” and “Beyond the Application Pro¬ 
gram: A Different Approach to Integrated 
Software,” pp. 100-262. 

K. Skier, “The Zenith Z100,” pp. 268-278. 

S. Barry and R. Jacobson, “The TRS-80 
Model 16B With Xenix,” pp. 288-320. 

M. Haas, “Naturallink to Dow Jones 
News/Retrieval,” pp. 324-334. 

L. Wheeler, “Bubbles on the S-100 Bus: Part 
1—The Hardware,” pp. 362-380. 

J. T. Maxwell III and S. M. Ornstein, “Mock¬ 
ingbird: A Composer’s Amanuensis,” pp. 
384-401. 

E. M. Carter and A. B. Bonds, “The VU68K 
Single-Board Computer,” pp. 403-416. 

J. Bass, “Translating the SAS Language Into 
Basic,” pp. 417-434. 

D. K. Broadwell, “Real-Time Clocks and PC- 
DOS 2.0,” pp. 442-450. 


Vol. 9, No. 2, Feb. 1984: 

G. Williams, “The Apple Macintosh Com¬ 
puter,” pp. 30-54. 

“An Interview: The Macintosh Design Team,” 
pp. 58-80. 

S. Ciarcia, “Build the Circuit Cellar Term-Mite 
ST Smart Terminal: Part 2—Programming and 
Use,” pp. 88-109. 

Special section—“Benchmarks and Perfor¬ 
mance Evaluation.” Articles include “Don’t 
Bench Me In,” “Beyond MIPS: Performance 
Is NOT Quality,” “Software Performance 
Evaluation,” “The Art of Benchmarking 
Printers,” “Benchmarking Fortran Com¬ 
pilers,” “Benchmark Confessions,” “The 
Word Processing Maze,” “Evaluating Word 
Processing Programs,” pp. 158-246. 


Books 

H. Anbarlian, An Introduction to Visicalc 
Spreadsheeting for the TRS-80 Model III, 
McGraw-Hill Book Co., 1983, 434 pp„ $49.95 
(includes disk). 

H. Anbarlian, An Introduction to Visicalc 
Spreadsheeting for the TRS-80 Model II and 
Model 16, McGraw-Hill Book Co., 1983, 350 
pp., $49.95 (includes disk). 

M. Banahan and A. Rutter, The Unix Book, 
John Wiley & Sons, Inc., 1983, 218 pp., 
$16.95. 

M. Brady et al„ eds., Robot Motion: Planning 
and Control, MIT Press, 1983, 585 pp., $37.50. 

S. Crop and D. Mosher, Portable Computers, 
Sybex Inc., 1984, 103 pp., $7.95. 

T. A. Dwyer and M. Critchfield, Pocket Guide 
to CP/M, Addison-Wesley Publishing Co., 
1983, 50 pp., $7.25. 

L. Finkel and J. Brown, TRS-80Data-File Pro¬ 
gramming, John Wiley & Sons, Inc., 1983, 306 
pp., $14.95. 

R. H. Flast, 54 Supercalc Models, Osborne/ 
McGraw-Hill, 1983, 244 pp., $15.95. 

O. Kellogg, The Radio Shack Notebook Com¬ 
puter, Sybex Inc., 1984, 118 pp., $8.95. 


T. King and B. Knight, Programming the 
M68000, Addison-Wesley Publishing Co., 
1983, 154 pp., $12.95. 

F. T. Leighton, Complexity Issues in VLSI, 
MIT Press, 1983, 139 pp., $19.95. 

T. G. Lewis, Pascal for the IBM Personal 
Computer, Addison-Wesley Publishing Co., 

1983, 406 pp., $15.95. 

D. Muller, Dictionary of Microprocessor 
Systems, Elsevier Science Publishing Co., Inc., 

1984, $67.50. 

L. Poole, Apple II User’s Guide, Osborne/ 
McGraw-Hill, 1983, 482 pp., $17.95. 

J. Sachs, Your IBM PC Made Easy, Osborne/ 
McGraw-Hill, 1984, 438 pp., $12.95. 

P. A. Sand, Advanced Pascal Programming 
Techniques, Osborne/McGraw-Hill, 1984, 370 
pp., $19.95. 

M. Waite, D. Martin, and S. Prata, Unix 
Primer Plus, Howard W. Sams & Co., Inc., 
1983, 414 pp., $19.95. 

M. Waite and C. Morgan, Graphics Primer for 
the IBM PC, Osborne/McGraw-Hill, 1983, 
440 pp., $21.95. 
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R. Moore, “ProDOS” [software review], pp. 
252-262. 

T. R. Clune, “The IBM CS-9000 Lab Com¬ 
puter,” pp. 278-290. 

C. Weger, “The Rixon R212A Intelligent 
Modem,” pp. 292-300. 

R. Jones, “IBM/Apple Communication,” pp. 
331-340. 

J. D. Blagg, “A Low-Cost, Low-Write-Voltage 
EEPROM,” pp. 343-344. 

K. Christian, “Inside a Compiler: Notes on 
Optimization and Code Generation,” pp. 
349-366. 

J. E. Roskos, “Writing Device Drivers for MS- 
DOS 2.0 Using Tandon TM100-4 Drives,” pp. 
370-380. 

R. Sussman and T. Sussman, “Five Original 
Graphics,” pp. 388-391. 

L. Wheeler, “Bubbles on the S-100 Bus: Part 
2—The Software,” pp. 395-414. 

D. F. Hinnant and M. B. Smith, “Bullet-Proof 
Pascal Input,” pp. 428-434. 

J. L. Star, “Favorite Benchmarks,” p. 436. 


Computer 

Vol. 17, No. 1, Jan. 1984: 

J. Grinberg, G. R. Nudd, and R. D. Etchells, 
“A Cellular VLSI Architecture,” pp. 69-81. 

J. W. Balde, “IEEE Computer Packaging 
Committee Spring Packaging Workshop,” pp. 
83-86. 

Vol. 17, No. 2, Feb. 1984: 

H. U. Steusloff, “Advanced Real-Time 
Languages for Distributed Industrial Process 
Control,” pp. 37-46. 


Datamation 

Vol. 30, No. 1, Jan. 1984: 

J. Raloff, “Keeping Pace,” pp. 38-46. 

G. D. Brown and D. H. Sefton, “The Micro 
vs. the Applications Logjam,” pp. 96-104. 

M. Tyler, “Touch Screens: Big Deal or No 
Deal?” pp. 146-154. 

Vol. 30, No. 2, Feb. 1984: 

Special issue on IBM. Articles include “The 
Song Remains the Same,” “Battle of the Baby 
Blue Boxes,” “Big Blue’s Big Bucks,” “An 
End to Flandholding,” “With a Little Help 
From Some Friends,” “The Legend of the Jol¬ 
ly Blue Giant,” “Mainframe Maneuvers,” 
“Software Strategies,” and “Assessing 
PROFS,” pp. 104-192. 


Dr. Dobb’s Journal 

Vol. 9, No. 1, Jan. 1984: 

N. C. Shammas, “NBasic: A Structured 
Preprocessor for MBasic,” pp. 24-34. 

E. Mitchell, “A Simple Window Package,” 
pp. 36-43. 


D. Cornell, “Forth to PC-DOS Interface,” pp. 
44-59. 

D. Daetwyler, “Sorted Diskette Directory 
Listing for the IBM PC,” pp. 60-74. 

Vol. 9, No. 2, Feb. 1984: 

K. Coye and A. Grossman, “Micro to Main¬ 
frame Connection,” pp. 20-24. 

L. Brooks, “Communications Protocols: 
Theory and Practice,” pp. 26-29. 

J. Fleming, “Virtual Personal Computer,” pp. 
32-59. 

R. S. Broughton, “Basic Language Telecom¬ 
munications Programming,” pp. 64-69. 


EDN 

Vol. 28, No. 24, Nov. 24, 1983: 

W. Twaddell, “Standard-Cell Design Inroads 
Spur Specialized Gate-Array Growth,” pp. 
49-58. 

R. E. Peterson, Jr., “Flat-Panel Displays,” pp. 
102-127. 

A. Rappaport, “Hands-On Timing Verifica¬ 
tion Validates IC Design Techniques,” pp. 
147-162. 

A. J. Hennigan and E. Zanelli, “High-Power, 
Dual-Bridge ICs Ease Stepper-Motor-Drive 
Design,” pp. 167-177. 

V. J. Coli, C. Hastings, and S. Rajpal, 
“Bipolar Arithmetic Chip Speeds 68000’s Math 
Throughput,” pp. 179-193. 

B. Collis, “Macros Speed 8080, Z80 
Multiplication,” p. 225. 

M. W. Johnson, “Absolute-Value Code Ex¬ 
ecutes Quickly,” p. 228. 

Vol. 28, No. 25, Dec. 8, 1983: 

B. Travis, “High-Performance Single-Chip 
pCs Provide Powerful Options,” pp. 52-73. 

G. Legg, “Minicomputer-Hosted Compilers 
Ease qP Software Development,” pp. 270-276. 

R. Comerford, “High-Level Graphics Tools 
Hasten Data Interpretation,” pp. 40-48. 

T. Ormund, “Latest Keyboard Improvements 
Stress Ergonomic Considerations,” pp. 
106-116. 

C. H. Small, “Enhanced Signature Analyzers 
Ease pP-System Diagnosis,” pp. 168-178. 

Vol. 29, No. 1, Jan. 12, 1984: 

A. Rappaport, “Semicustom-IC Users’ Needs 
Determine Technology Development,” pp. 
75-86. 

J. McDermott, “Digital Motion Control,” pp. 
124-152. 

J. E. Hemenway, “Powerful VME Bus 
Features Ease High-Level pC Applications,” 
pp. 158-168. 

“1983 Technical Article Database Index,” pp. 
177-250 [Note: An index of articles that ap¬ 
peared in EDN, Electronic Design, Electronics, 
Electronic Products, and Computer Design ]. 

D. Garde, “Single-Port Multiplier Reduces 
DSP System Costs,” pp. 277-286. 


Electronics 

Vol. 57, No. 1, Jan. 12, 1984: 

S. Joshi and V. Iyer, “Protocols and Network 
Control Chips: A Symbiotic Relationship,” pp. 
157-163. 

S. J. Frank, “Tightly Coupled Multiprocessor 
System Speeds Memory Access Times,” pp. 
164-169. 

Vol. 57, No. 2, Jan. 26, 1984: 

E. L. Keller, “Automotive Electronics Shift 
Into Overdrive,” pp. 101-112. 

J. Munday, “Three-Chip Set Offers Univer¬ 
sal Cost-Effective SLIC,” pp. 116-119. 

N. R. Vemula, “Single IC Can Perform Speech 
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ADVANCE ANNOUNCEMENT 


COMPCON FALL '84 will focus on the (Revolu¬ 
tionary impact of rapidly evolving computer tech¬ 
nology on the modern world. MICRO, MINI, and 
PERSONAL COMPUTERS are beginning to 
touch all aspects of our lives. They affect how we 
think, how we act, how we work, how we play, 
and even our health. Their influence is explicit as 
tools—for management, for science, for adminis¬ 
tration, and implicit as embedded controls in 
many other systems—automobiles, industrial ro¬ 
bots, and consumer products. 

Advancing computer hardware technology has 
driven down the cost, size, weight and power con¬ 
sumption to make small computers appropriate 
and affordable on a scale almost unthinkable as 
recently as a few years ago. New applications of 
small computers, from single chip micro proces¬ 
sors to desk top minis, are expanding at an explo¬ 
sive rate. The scope of applications seems limited 
only by human imagination. The SMALL COM¬ 
PUTER (R)EVOLUTION, COMPCON FALL '84 
program will encompass a wide scope of applica¬ 
tions: as tools for managers, professionals, non¬ 
professionals, students, home-users, hobbyists 
and as embedded elements of other systems. The 
program will include tutorials, panels, demonstra¬ 
tions, and technical papers. 

Mini Thtorials will be held on Sunday Septem 
ber 16, 1984 from 1:00 p.m.-5:00 p.m. 

• Introduction to Computer Applications 

• End User Facilities 

• Introduction to Computers 

• Software Quality Assurance 

Full Tutorials will be held on Monday Septem¬ 
ber 17, 1984 from 9:00 a.m.-5:00 p.m. 

• Local Network Technology 

• Distributed Data Bases 

• Ada 

• C Language on Small Computers 


Session topics will include (but not be limited to) 
new products, support software, application pack¬ 
ages, user friendliness, embedded systems, hard¬ 
ware technology and architecture of small com¬ 
puter applications and end products. In addition 
to the world of applications (above), papers and 
demonstrations are invited on: 

• Data/Computer Security 

• Networking 

• Electronic Mail 

• Economic/Social Impact 

• Graphics 

• Robotics * CAD/CAM 

• Simulators 

• Computer Aided Instruction 

• Artificial Intelligence 

• Software Ownership Protection ’ 

• Computers for the Handicapped 

And other areas of interest in the realm of the 
SMALL COMPUTER (R)EVOLUTION 

PRIZES WILL BE AWARDED FOR THE BEST 
PAPER ON NEW APPLICATIONS, THE BEST 
UNDERGRADUATE PAPER, AND THE BEST 
DEMONSTRATION OF THE USE OF SMALL 
COMPUTERS. Your papers and suggestions for 
special sessions, panels, tutorials and demonstra¬ 
tions are solicited. 

SPECIAL EVENTS TAKING PLACE: 

• Vendor Exhibits 

• Micro Computer Swap Meet 

Sunday, September 16, 1984 from 10:00 a.m- 
6:00 p.m. at Hyatt Regency Crystal City 

• Cocktail Party 

Tuesday, September 18, 1984 

• Special Noontime Session 

Wednesday, September 19, 1984 
Featured speaker and luncheon 


the instituted electrical and electronics ENGINEERS, INC. 





